Starting a software project from The Domain

4 min readDec 22, 2021

Software design is a complex task in development work. Maybe the hardest. And of course, it is the starting point. DDD gives you The Domain.

There are many guides and formal methodologies to accomplish such a job. I want to show you how to use a simplified version of Domain Driven Design.

Why DDD? Because this methodology centers the effort on the understanding de business problem and materializing your knowledge on a domain model. As opposed to others more data or technology-centered.

Why simplified? Well, D.D.D. shines brightest in really complex systems; And in most cases, you will be working on medium-sized projects, so a simplified approach will suffice.

⛈️ Event storm

Is a meeting where all domain experts could be asked for their business point of view. The goal is to get a series of business processes that mimics the function desired for the system being constructed.

Those business processes are called domain events and are the cornerstone of The Domain.

🏛️ The Domain

This is the entire subject area of specific knowledge related to the business we are modeling. We need to understand it as much as we can. And at least we need to know who is the expert in charge that can help us.

A humble starting thought is that if someone wants to pay us for creating software is because he has a problem. Inside the domain is hidden the problem space.

💫 The problem space

In DDD, the problem space is the entire set of relevant concepts, processes, rules, and events that occur throughout the organization that we’ve been asked to build software for.

🟧 Events

Something that happened in the domain (expressed in past tense) and that usually is notified to other parts that usually react to the event.

Should be time-aligned, and admits parallel swimlanes of concurrent events.

Also is important to mark some events as pivotal. Events that change or affect the domain in a huge way.

🟨 Actors

Actors are people or generic user roles that interact with the domain.

🟦 Commands

Commands are processes launched by actors, that usually generate an event.

So our first job is to know what we have to solve, creating lists for each category. That will be the foundation for any other documents and diagrams.

🗺️ Context diagram

There are a lot of diagraming paradigms that help us transmit the problem understanding and solution offered. Even D.D.D. has its own set of proposed diagrams.

But at this point, I feel more comfortable using the C4 diagram model. In a nutshell, is an “abstraction-first” approach to diagramming software architecture, based on a series of four well-defined levels:

Context -> Containers -> Components -> Code

Each level zooms in a section of his parent, and this allows you to get to the detail needed for your project. But it is mandatory to start with the context diagram.

🎨 Subdomains

Remember divide and conquer. A subdomain is a part of a domain that makes senes for itself. But not all subdomains are created equal.

💓 Core subdomains

The fundamental part of the domain. Is so critical that, without this, there is no reason for the domain to exist.

🍏 Supporting subdomains

These are necessary pieces to complete (support) the activity of the core subdomains. Is important to note, that although being auxiliaries they are required.

👖 Generic subdomains

In this category falls any activity that can be outsourced, or even been a ready-made solution.

🚀 Applied to Astro Bookings

AstroBookings: Our pet-lab-sample-demo project.

We have got simulated letters with requirements sent from our simulated client, Astro Bookings Corp. After reading them, we have scheduled a simulated online meeting to perform an Event Storm session.