Back to VSLive! San Francisco Show Daily Home

email article printer friendly more resources

Simplify Your Efforts With DDD
Learn how to streamline your apps from the beginning with domain-driven design.
by Jimmy Nilsson

February 1, 2005

If you've chosen the domain model pattern when structuring the main logic of your new application, you are focusing on building an object model that describes not only the data and relationships of your concepts, but the behavior as well. This is a big step in the right direction for many applications.

But you're not done yet. You need to pay close attention to the domain model's design, otherwise its power will evolve rapidly into a mess devoid of structure and too flexible to manage. This is where domain-driven design (DDD) comes in. DDD provides you with a toolset and sense of style that help you create a successful domain model, getting you on the right path from day one.

Simplicity is Key
KISS—or, "Keep It Simple, Stupid"—is one of the key rules to remember when working with DDD. For example, instead of letting all classes in the domain model connect to all other classes, you should try to limit these relationships as much as possible to keep things simple. This holds true for navigation as well—avoid bidirectional relationships as much as possible. Such relationships not only add to the domain model's complexity, but they also make the domain model more tightly coupled when it's complete.

Consider this example. Assume you have two classes: Owner and Dog. An Owner can Whistle(), and a Dog can Run() and Bark(). Though an Owner can have several Dogs, each Dog can have only one Owner. In reality a Dog could have several Owners, but if this functionality isn't important to your application, you shouldn't increase the complexity by using many-to-many multiplicity. Remember that models aren't the reality; they are abstractions and simplifications of it.

Now, assume your application contains logic and scenarios that necessitate you to go from a Dog to its Owner, but you also have the need to show an Owner and all of his or her Dogs in a form or two. Here you have a need for bidirectionality, right? True, but this is not the same as saying there must be bidirectionality contained as physical links between these two classes. You can choose to link them in the most crucial direction and let the consumer use a repository to navigate in the other direction.

Repositories Help Factor Out Certain Logic
You can use repositories for querying the domain model; for example, you can use them to fetch all the Dogs for a certain Owner. Repositories deal with the middle and the end of the lifecycle of the domain model objects; repositories help remove unnecessary functionality from your classes so they can stay as simple as can be. Basically, they act as a good way of achieving a separation of concerns in your domain model. For example, lifecycle support and querying do not comprise the core responsibility of a domain model class such as Dog. Therefore, you can factor this out into repositories and make the Dog class even simpler and cleaner.

To take a metaphorical approach, I'll compare this with books. Books are readable—this is a responsibility of a book. But a book is not responsible to know where other books are located within a library—the librarian is responsible for this. So, the librarian is our repository. The book also isn't responsible for putting itself on the correct shelf; again, this responsibility is factored out to the librarian. Imagine how complex a book would be if it needed to know the locations of all the other books in the library and be able to move itself to the right shelf.

At the same time, having this functionality in the domain model is a good thing—not in the Book class itself, but in a repository class. Essentially, letting the consumer of the domain model (such as a Presentation Layer) be responsible for the searching functionality of books often doesn't make the most sense. This gives the Presentation Layer too much responsibility for most applications and can lead to errors.

Now you're thinking, that's actually how it works quite often in the library—you as the consumer of the library will have to try to find the books on your own. I mentioned that repositories deal with the middle and end of the lifecycle, so now I'll explain how factories deal with the beginning.