November Architect: Domain Model Structure - Part 2: Entities

Last month, we started a discussion around how to organize classes inside your domain model in a clear, easy-to-understand, and easy-to-maintain way. We reviewed our objectives and discussed why they are important. This month, we will start revealing a story of a business domain for the purposes of developing a software application. We will look into what is being managed in the domain day to day: Entities.

Discovering Entities

There are a number of technical definitions of an Entity that are popular in the industry. For example, here is a definition from Eric Evans' book Domain Driven Design, p. 89: An object that is not fundamentally defined by its attributes, but rather by a thread of continuity and identity.

The way I prefer to think about Entities is what we manage in our domain day after day. Entities span through long periods of time and run across multiple systems. They often have lives well beyond our applications and must be effectively tracked. As a general rule, assume that mistakes in Entity identification and tracking are expensive to notice and repair.

To discover Entities in your domain, talk to your functional people and end users. Ask them to walk you through scenarios the new system should implement. How are your users going to use your application? What is important to them and why? What do they really care about? What is important to your company and how does it need to be reported? The chances are you will be talking about what needs to be tracked and how, thus you will be talking about Entities.

Examples: Person, Account, Loan, Application, Payment.

Entity Relationships

What are the relationships between your Entities? Before getting into technical details, create a simple analysis diagram that shows the Entities you have discovered and their relationships. Lets consider a simple example:

Scenario 1: User logs in into the system to check the status of their applications and loans.

Scenario 2: User calls a Customer Service Representative (CSR) to reset their password.

Entity Relationship

Your research and conversations about the domain model revealed 4 Entities: Account, Person, Application, and Loan. Let us walk through the first scenario:

  1. User logs in into the system. The system needs to retrieve the user's security Account and verify their username, password, and any additional validation factors.
  2. Upon successful login, the system retrieves a previously stored Person record based on Account information. Thus, you see an arrow from Account to Person. You learned that each Account has a corresponding Person record, but not all People have created an online Account. That explains the numerical values on the diagram.
  3. Based on Person, the system retrieves their Application and Loan information. Thus, the arrows are shown from Person to Application and Loan. Person is created on the system with their first Application, but not all Applications are approved to become a Loan. Notice that there is no arrow between Application and Loan - we cannot determine its direction based on our current scenarios.
Now, let us take a look at the second scenario:
  1. User cannot verify the security information during login and calls CSR to reset their password. CSR asks them a series of Personal questions and retrieves their Person record.
  2. CSR retrieves the user's Account record for additional verification and resetting the password. Thus, you see an arrow from Person to Account.
Do not worry about having a circular dependency between Account and Person on the Analysis diagram. In one of our next articles, we will show several implementation options for the relationships. We will not have a circular dependency in the final implementation.

Domain Model Structure

Account, Person, Application, and Loan are our first classes in the Domain Model. For now, place them together in a sub-folder under the Domain Model root. We name this folder "Operation":

Domain Model Structure - Operation folder

Summary and Additional Tips

  1. Entity is an object that is not fundamentally defined by its attributes, but rather by a thread of continuity and identity.
  2. Entities span through time and space and are being tracked and managed in the day-to-day operations.
  3. Discover Entities by talking to your functional and end users. Create simple Analysis diagrams as a result of these conversations.
  4. Entity's primary responsibility is to maintain its continuity. Keep it simple by leaving complex behaviors out of its class definition.
  5. Managing life-cycle of Entities is a complex and risky job. Try to keep the number of Entities in the system down. Too many Entities will defuse your model and create no value.
  6. Compare Entities of the same type by their identity regardless of their form and history. Make identity type a Value Object.
  7. If you are interested in creating a simple base Entity class, you can start with the one listed below:

    ///<summary>Base Entity Class </summary>
    public class Entity <T>
    {
        public T ID { get; protected set ; }
        public static T NewID { get { return default (T); } }

        ///<summary>Returns true if the object has not being stored in the system. </summary>
        public bool IsNew { get { return Equals(NewID, ID); } }
        public Entity(T id) { ID = id; }
    }

Happy coding! To be continued...

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.

Objectives

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.

Summary

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...

August Architect: .NET Solution structure

Problem Statement

Last month, I blogged about organizing code in a source control system. We looked at how release units help us represent a domain context map to support domain-driven design and distributed application development. We recommended adopting a standard release unit layout so that your release process can be clearly understood and automated.

This month, we will take a deep dive into the release unit's trunk folder. I said before that trunk contains the latest version of the release unit code. How shall we organize our code inside trunk?

Objectives

As always, let's define our objectives:

  • Support domain-driven design philosophy
  • Support principles of object-oriented design
  • Support distributed application development
  • Support a structured, repeatable, and traceable release process

Release Units in .NET

Release Unit is a collection of folders and files that are released together. In .NET environment, this is achieved with a .NET solution that groups multiple projects together for the purposes of debug, compilation, and release. Hence, if you are working in .NET environment:

Each release unit should contain one and only one .NET solution.

.NET Solution Structure

Now, we are ready to take a look at a sample .NET solution structure that will help you implement principles of domain-driven design and object-oriented programming. For simplicity, let's assume our solution consists of a single web application and a command-line data setup utility. You will have no problems extending this approach to handle your own more sophisticated scenarios.

.NET Solution Structure

/doc - contains release unit's documentation.

/lib - contains release unit's pull dependencies. When your project uses a .NET assembly not part of your solution, place the assembly into the lib folder and reference it from there. It ensures that all projects in the same solution always use the same version of the dependent upon library and provides you with a clear way to upgrade the library to a new version should you decide to do so.

/Database - contains database creation and modification scripts, scripts to set up users and their permissions, load data files, etc. This folder may also include command-line batch files to set up the release unit on a local machine, build, integration or test server.

/Model - contains classes of the Domain Model, a central part of the release unit. This assembly describes what can be accomplished by the release unit in business terms. Keep the model free from infrastructural detail. It will help you achieve high levels of reuse and low costs of maintenance in your applications. Next month, we will take a look at how to organize your domain model to clearly identify all supported business scenarios and transactions. This is a big topic on its own, which certainly deserves a dedicated blog article.

/ModelUT - contains unit tests for the Domain Model classes.

/Persistence - implements a persistence mechanism for the release unit's domain model. I strongly recommend keeping persistence interfaces with the model itself since it shows how aggregates and entities are designed to be loaded into memory. The purpose of the persistence library is to implement persistence interfaces with your standard tools and techniques.

/PersistenceUT - contains configuration files and unit tests for the Persistence. In our case, these tests verify the release unit's persistence classes and their configuration files as well as the database. Strictly speaking, they are integration tests. However for the purposes of the domain modeling, we prefer to think about the whole domian model persistence as a black box.

/WebInfrastructure - contains web infrastructural classes which would otherwise be placed in the App_Code directory on the web site. Extracting these classes into a dedicated library allows them to be unit tested.

/WebInfrastructureUT - contains unit tests for the web infrastructural components.

/Web - contains a web application, a top application layer responsible not only for user interface but also for referencing and configuring all its depencies.

/WebUAT - contains user acceptance test scripts, such as Selenium or WatiN.

/WebLT - contains load testing projects, such as JMeter or LoadRunner.

/DataSetup - contains a command-line process to perform backroom administrative tasks.

/DataSetupUT - contains unit tests for the data setup components.

Dependencies

To better understand this sample solution structure, take a look at the package diagram below:

Package Diagram

Summary

  1. For each release unit, create a .NET solution file.
  2. Place all of your external pull dependencies into the lib folder.
  3. Keep your model classes free from any infrastructural detail.
  4. Make your top layer responsible for connecting and configuring all its dependencies.

Happy coding!

July Architect article updated

Based on the comments received, I have updated my last month's article in the Architect column. In the end of the article, you will now find a 5-step summary on how to structure your source control repository in order to support:

  • Domain-driven design philosophy
  • Distributed application development
  • Structured, repeatable, and traceable release process

Thank you for reading Modelus Blog!

July Architect: How to organize your code in Source Control System

Problem Statement

One of the first questions facing development teams is deciding how to organize their code in a source control system. In this article, I will describe an approach that we have applied successfully at multiple organizations over the last decade. I hope it will help you and your team make your development environment and processes leaner and more efficient.

Objectives

First, let's understand what capabilities we are looking for from our source control system:

  • Support of the domain-driven design philosophy
  • Support of a distributed application development
  • Support of a structured, repeatable, and traceable release process

Release Unit

Our source control system is organized around release units. Release Unit can be thought of as a collection of folders and files that are released (and thus, reused) together. It is a job of application architecture to break down a large monolithic application into multiple release units so that they can be tackled independently by different development teams.

Pull and Push Release Unit Dependencies

We recognize two types of dependencies between release units: Push and Pull. Let's assume that Release Unit A depends on Release Unit B. Push dependency means that every time B is changed, it is automatically integrated with A. Pull dependency means that B is integrated into A when A's development team decides to pull a new version of B into A.

An example of Pull Dependency: an application that depends on a shared domain. Even though a new version of the shared domain may be released each month, it does not force the application to be integrated, tested, and redeployed on a monthly basis. Instead, the application integrates with the shared domain only when the application development team decides to pull a new version of the shared domain into the application.

An example of Push Dependency: a web application that depends on the portal's header and footer. Every time, the new header and footer are implemented, each web application is automatically integrated with the new header and footer code.

Implementing Release Unit

We recommend to store a release unit in its own source control folder with the following layout:

/trunk - contains the latest version of the release unit code (may be in progress)
/tags - contains read-only copies of the code (e.g., previous releases of the code into production or test environments)
/branches - contains branch copies of the code

Implementing Pull Dependency

Create /lib folder in your release unit's trunk and place all release unit's pull dependencies there. Configure your release unit to automatically integrate with the dependencies placed in the lib folder. Next month, I will demonstrate how to set up a sample .NET solution structure with pull dependencies.

Implementing Push Dependency

Configure your release unit to link and automatically check out or export all its push dependencies. In Subversion, this can be achieved by using the svn-externals property.

Organizing Release Units

Even a medium-sized organization is likely to have hundreds or even thousands release units in their source control repository. In order to keep the repository manageable and easy to navigate, group release units belonging to the same bounded domain contexts together. For example, you may have a set of release units stored in the Accounting folder, another set stored in the HR folder, and another set stored in the Finance folder. You will need to refer to your domain context map in order to learn what bounded contexts exist in your organization.

5-Step Summary

  1. Structure source control to represent your domain context map
  2. Develop your applications using multiple release units
  3. For each release unit, assign ownership to a dedicated development team
  4. Integrate release units via Push and Pull dependencies
  5. Establish standard integration and release processes for all release units

Contact me if you have any questions or comments. Happy coding!

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!

Authors

Search

Archive

Tags