October Architect: Domain Model Structure - Part 1

Problem Statement

In August, I blogged about the structure of a release unit's trunk folder. We looked at how to organize your .NET solution to support principles of object-oriented and domain-driven design and distributed application development. We recommended creating a separate library for domain model classes that would describe your release unit's capabilities in business terms.

This month, we are starting a discussion around how to organize classes inside your domain model in a clear, easy-to-understand and, thus, easy-to-maintain manner that supports natural growth of your applications. The topic is quite large and will take a series of articles to cover even at a very high level. The purpose of this article is to introduce you to the topic and provide basis for our discussion over the next few months.


As always, let's define our main objectives:

  • Support on-the-project learning
  • Organize development of the domain model in a structured evolutionary manner
  • Have the domain model tell a story
  • Make rules and operations explicit and extendable
  • Support domain-driven design philosophy
  • Support principles of object-oriented design

Why are these objectives important?

Support on-the-project learning

When all decisions are predetermined before the implementation, a significant amount of business value is lost:

  1. Learning that occurs during the project is ignored because it is not a part of the original plan.
  2. Communication between users and stakeholders and the development team is poor.
  3. Very limited creativity takes place. There is almost no place for new ideas.
  4. As a result, the system is created lacking flexibility and understanding of the domain.
To get the most out of your projects, enable continuous functional and technical learning for all your team members. As they learn more, they will make decisions better and faster.

Organize development of the domain model in a structured evolutionary manner

There are two major alternatives to Structured Evolutionary Design:

  1. Big Design Up Front (BDUF), in which design decisions are perfected before the implementation is started.
  2. Adhoc Evolutionary Design, in which design decisions are made as the system is being developed, but without a set of rules that would ensure domain model consistency.
As your team acquires new knowledge, their understanding of the domain changes. Even if you start with BDUF, the domain model needs to evolve in order to correctly represent your understanding of the business situation.

As your domain model evolves, it becomes more powerful and sophisticated, requiring you to establish rules and guidelines around it. Without overarching rules, constant changes to the model will make it inconsistent and hard-to-understand, eventually leading to a familiar "fast-slow-stopped-redesign" application development cycle.

Have the domain model tell a story

An ability of the domain model to tell a story is one of the most critical design objectives. OO allows us to build classes representing real-world business concepts. Should not we be able to use them to describe a business situation? Ask the following questions during your next design or code review:

  • What business processes are enabled by this system and what are their steps?
  • What business transactions are supported and how are they implemented?
  • What business concepts do we deal with day-to-day? How are they described? How can they be created and loaded into memory?
  • What operations are performed? What decisions do we face? What business rules could be customized and how are they configured?

Make rules and operations explicit and extendable

Business rules and operations are often the most sophisticated and the most changeable classes in the domain model. But most importantly, these classes have a great potential to add a hidden business value. Make them explicit and extendable in your model to uncover their true power.

Support domain-driven design philosophy

If you are new to domain-driven design, please, refer to this book to get started.

Support principles of object-oriented design

There is plenty of information online about the object-oriented principles. They are a great way to maintain a clear, flexible, reusable, and robust codebase and keep infrastructural details outside of the domain model.


This article started a discussion around how to organize your domain model. We have reviewed the objectives and discussed why they are important. Next time, we will look closer into designing domain model in practice.

Happy coding! To be continued...

Welcome to ModelBlog

Thank you for visiting ModelBlog. We hope the time you spend with us will be both entertaining and worth your while. Have fun!