Apply a Domain-Driven Design Approach to Development

Now, imagine you've met two different clients. They've received their final software product, and they've just finished testing out the solution. Now, based on the reactions below, which of these customers received the software they really wanted?

It's obviously Customer A! Now, how was she able to get that perfect software and avoid feeling like Customer B? Because the developers and customers were on the same page about what was to be delivered. That’s not an easy thing to accomplish. Software developers want to create effective solutions, but are often focused on making the software and forget to think about who they're building it for! This leads to unhappy customers, which means having to fix and change the original design and taking more time, work, and money. 

One way of giving you a fighting chance for success is by collaborating with stakeholders using domain-driven design to build and use a  domain model. 

What Is a Domain Model? 

A domain model is a conceptual representation of the major items that must be understood to build a system the customer wants. You can think of it as the foundational design of a system, but one that both stakeholders and developers can understand.  

Think of a story. If you were going to tell someone about it, what would you say, and what would you skip? Very simply, if you talk about it, it's a major item. If you leave it out, it's minor. The main character(s) is major. Any obstacle they must overcome is too. The fact that the character has to travel to Paris is another. That they sat in seat 45F is not. This grouping of major items is your domain.

If the author writes a sequel (i.e., the customer wants more features), some of the ideas will be grouped with the major items in the original domain. But since it's a new story (feature), there will be elements that are separate from the first. These would become part of another domain.

Yes. When dealing with big or complex domain models, you'll group elements into separate domains. These are called bounded contexts. How does this work? Here's an example you are familiar with: a school classroom. Let's say you're going to write a software system to help support the school.

When you start, you have the logistics of the class. It meets in a certain room on certain days. Also, there is an assigned instructor along with students who are taking the class. Homework, quizzes, tests, and grades need to be recorded. All this infrastructure must be managed by your system. Hey, this is making sense!

But now someone starts talking about the financial side as well. The teacher needs to be paid and the classroom's electric bill as well. All of those students are paying tuition. So the same concepts (students, teacher, classroom) begin to have additional meanings. Yeah, this is starting to get messy.

By breaking it out into separate domains!  😎 You seem to have stumbled upon two domains (so far). The logistical and the financial, but that's good. Later you'll see that each domain has a unique perspective on these similar concepts.

If you skipped the domain modeling approach, you would build a system that added each of these ideas in an ad hoc manner, generating an unmaintainable system. Instead, by starting with a domain, you will use a customer-based, or top-down, approach. You are trying to understand the what and why of the solution you need to build, rather than focus on how you build it. A domain model describes these key concepts of what and why, and spells them out in terms that everyone can understand.  

Why is this so important? Well, let’s give this a try by role-playing a client (me) and a developer (you). Let's see if we can both come up with the same definition for something simple: a book. Think about it. What is a book?  Go ahead and write down a definition.

Have you got yours? Alright, here’s my answer: A physical item that can be checked out from the library.

Exactly! 😉 Now you know why writing code to please customers without collaborating with them is so difficult. You need to understand the terminology and context of your customers. Even simple terms might mean something different to various people in multiple contexts. Don't make assumptions! Conversations are the key! 

What Do Domain Models Look Like?

There are many ways to capture a domain model. This can be in the form of bullet points on wiki pages, or something much more formal. One of the most common ways is to use diagrams: 

As you can see, this is not a model of the system from the system’s perspective. We are not concerned with databases, objects, cloud deployment, or any other technical implementations at this point. (That is the bottom-up approach, which is concerned with how to build.)

Reap the Benefits of Using Domain Models

You benefit from building a domain model - otherwise, why would you bother? The biggest advantage is that developers understand the system from a business perspective. That is, how the business is trying to make money while keeping and gaining customers. And business is all about change. Since they want to retain customers and add new ones, they will dream up features to make customers happy. If you build a system from a domain viewpoint, the changes are usually easier to implement. Let's take a look at another example: 

This diagram illustrates the major ideas associated with a taxi company. As you can see, many things center around a Ride. Clients want them. Drivers in Cars provide them. Also, payment is made for each ride, which includes information about Locations.

Now, look at the Payment item in the domain model from the section above. It is not specific. It doesn't say "Cash" or "Credit Card." It's open-ended enough that you could accept cryptocurrency if the business side determines enough clients want to pay that way.

You could build a system from the system perspective and how it's going to be implemented from a technical standpoint. But so means any requests for changes become problems, instead of opportunities. You also risk making critical design mistakes early on, which push you towards messy tinkering, backtracking, and general "fitting a square component into a round system" issues. It ultimately leads to more fragile systems.

But don’t worry, you will have to code eventually. 😉

If you understand the big picture, you can build more maintainable, flexible software. In a future conversation, one of your system users may discuss an entirely new action that they want. It will be easier to determine if that new action requires new ideas added to the domain, or if it uses existing ideas differently.

It's Your turn!

Now, practice modeling the big picture! Think of a book you have recently read, or a favorite you have read many times. Capture a domain model of the book.

We haven't explored the actual modeling approaches, yet, so focus on the thought process. A simple list will suffice, or if you're familiar with UML diagrams, you can try your hand at that.  Use any format you like!  Your model should include any major characters, locations, and events that occur.

Here's a quick example:

• Snow White

• Dwarves

• Evil Queen

• Poison apple

• Magic mirror

• Jealousy

From these essential elements, I'm sure you can figure out that my story was Snow White and the Seven Dwarves! Now, set a timer for 10 minutes and extract the major items of your favorite story.

Let's Recap!

• Don’t start building code right away; start with models instead. 

• A domain model captures the essential elements of a system.  It makes it easier to communicate with clients about their needs and design maintainable software.  

• A domain model can have multiple domains or bounded contexts.

• The domain model can exist in many forms. Examples include UML diagrams, wiki pages, and the code itself.

• Capture what and why you need to build the system, not how.

Now that you know what a domain model is, we'll look at the steps needed to capture a domain model.