In my last article, we talked about Value Objects, domain model elements with no conceptual identity. We said that Value Objects represent descriptive aspects of the domain and are fully defined by their state. This month, we will review the options for loading Value Objects into memory.

Potluck Principle of getting Value Objects

The Potluck Principle states that if you need to obtain a Value Object in your code, you have the following three options:

You may be able to create the Value Object yourself

You may be able to ask another object to give the Value Object to you

You may be able to reconstitute the Value Object from a previously stored state

Option 1: Create Value Objects yourself

You can create a Value Object by calling it's constructor or factory. This is a very simple method but there is a catch: since Value Object are immutable, you need to know all their required attributes at the moment of construction.

Example: Creating an instance of the Address class based on a submitted HTML form.

Option 2: Ask other objects to give Value Objects to you

If you need a Value Object in your code, who could you ask for it? Since Value Objects are often descriptors, you may be able to query objects their describe (usually Entities or other Value Objects).

Option 3: Recreating a Value Object from a previously stored state

As discussed in my previous posts, Value Objects are tracked only as part of Entities they describe, in which case they are loaded into memory using Option 2. Value Objects are not recreated from previously stored states.

However, there is a situation when Value Objects need to be created independently. For example, it is a fairly common requirement to display the list of Value Objects in a drop-down list.

Example: User submits a new Purchase Order. As part of the entry screen, the user chooses Billing and Shipping Address for the new Purchase Order. All 50 States are selectable on the Billing Address form, but only 48 States are selectable on the Shipping Address form.

How shall we populate drop-down lists of 48 and 50 States for the New Purchase Order screen?

I have heard software designers making arguments towards promoting State to an Entity. Then, State Repository would be responsible for retrieving the right lists of States to display in each situation. I disagree with such design. It introduces a responsibility of managing States into the domain model, which can be easily avoided if we keep States as Value Objects.

Another important point against introducing the IStateRepository interface is that business rules of whether to display a particular State in a drop-down or not do not belong to the State class. For example, the company could introduce a new Product, which could be shipped to all 50 States.

My preference is to assign the responsibility of knowing about Value Object lists to aggregate repositories. In our example, IPurchaseOrderRepository would have FindStatesForShipping and FindStatesForBilling methods.

In the Part 2 and Part 3 of the Domain Model Structure series, we continued our discussion around how to organize classes inside your domain model. We defined Entities, looked at their relationships, and reviewed options for loading them into memory. This month, we will take a look at Value Objects.

Discovering Value Objects

Value Objects are domain model elements with no conceptual identity. They represent descriptive aspects of the domain and are fully defined by their state. Their behavior depends on what they are, not who they are. If they need to be tracked, they should be tracked with the elements they describe. Thus, they do not need an identity of their own.

We prefer to keep Value Objects immutable, i.e. changeable by full replacement only. Immutable Value Objects are safe to share (which increases performance), and easy to understand (which allows you to build complex behaviors). Let me give you an example based on a classical OO problem:

Assume you have two buckets of paint: b1 and b2. The first bucket b1 contains 1 gallon of yellow paint. The second bucket b2 contains 1 gallon of blue paint. Without looking into the code, could you answer the following questions about the results of the operation b1.Add(b2)?:

What will be returned by the Add method? Is it 2 gallons of green paint or nothing?

What will be in the the first bucket b1? Is it 2 gallons of green paint or 1 gallon of yellow paint?

What will be in the second bucket b2? Is it 1 gallon of blue paint or nothing?

If you notice, we do not have a requirement to track buckets of paint. Thus, I will assume that Bucket is a Value Object and should be immutable. Since both buckets are immutable, they will contain their original values of 1 gallon of paint each and the result of the Add operation will be 2 gallons of green. With no convention in place, it would be impossible to answer these questions without checking the code or better yet unit tests first.

You domain has many Value Objects, a lot more than Entities. If you are having troubles seeing them in your system, take a closer look at the Entities. How are they being described? What are their attributes and properties? How are they being searched for or ordered by? The chances are you will be talking about Value Objects.

Examples: Address, DayPoint, Money, Range, SSN, etc.

Domain Model Structure

Value Objects along with Entities are main elements of the domain model. Many of them are small simple classes that will be widely used in your application.
Place them together in a sub-folder under the Domain Model root. We name this folder "Capability":

You are likely to have a number of very complex Value Objects as well. I will try to discuss some of them in my future articles.

Last time, we continued a discussion around how to organize classes inside your domain model. We defined important domain model elements: Entities, aka Reference Objects, and looked at their relationships. This month, we will review the options for loading Entities into memory.

Potluck Principle of Getting Objects You Want

The Potluck Principle states that if you need to obtain a reference to an Entity in your code, you have the following three options:

You may be able to create the Entity yourself

You may be able to ask another object to give the Entity to you

You may be able to reconstitute the Entity from a previously stored state

Choosing the right option

The option #1 is usually implemented via a constructor or a factory. It works well when you need to create a new entity object, not yet tracked by the application.

As we discussed last month, Entities span through long periods of time and run across multiple systems. Unless you are writing a data entry application, you are going to work with existing Entities a lot more often than with new ones. When you need to create an existing Entity, use the option #2 or the option #3.

Let us take a look at the last month's example: User logs in into the system to check the status of their loan applications. Assuming we have a Person loaded, how shall we obtain their Applications?

To enable the option #2, design the Person class with a method or property that returns the Person's Applications. I generally prefer to pass a qualifier, such as loan type or date, that would transform one-to-many relationship between Person and Application into one-to-one with a qualifier, but this is a topic for another conversation. For now, let us assume that the Person class defines the Applications property that returns a list of Applications. This requires you to either get the Applications when the Person object is loaded into memory or implement a lazy load mechanism to defer loading Applications until the Applications property is called.

To enable the option #3, design the ApplicationRepository class with a method that returns a list of Applications for a given Person: "IList FindByPerson(Person person)".

Domain Model Structure

My preference is to place repository interfaces in the model and move repository implementation into a separate Persistence library. Keeping repository interfaces in the model helps clients understand how entities are supposed to be loaded into memory. Having repository implementation separate from the model keeps the model free from infrastructural detail.

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.

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

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.

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.

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:

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.

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":

Summary and Additional Tips

Entity is an object that is not fundamentally defined by its attributes, but rather by a thread of continuity and identity.

Entities span through time and space and are being tracked and managed in the day-to-day operations.

Discover Entities by talking to your functional and end users. Create simple Analysis diagrams as a result of these conversations.

Entity's primary responsibility is to maintain its continuity. Keep it simple by leaving complex behaviors out of its class definition.

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.

Compare Entities of the same type by their identity regardless of their form and history. Make identity type a Value Object.

If you are interested in creating a simple base Entity class, you can start with the one listed below:

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

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:

Learning that occurs during the project is ignored because it is not a part of the original plan.

Communication between users and stakeholders and the development team is poor.

Very limited creativity takes place. There is almost no place for new ideas.

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:

Big Design Up Front (BDUF), in which design decisions are perfected before the implementation is started.

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.

I am happy to announce a new monthly column called "The Architect" where we will touch on many issues facing designers and developers creating object-oriented business applications.

I will share with you rules, principles, and techniques that I found useful over the years. I hope you will be able to identify with the problems described and will take pleasure in learning from the situations that apply to you.

We have a wide scope to cover: object-oriented analysis and design, domain modeling, design patterns, domain-driven design, responsibility-driven design, service-oriented architecture, etc. If you are a member of a development team, or if you work with software developers, this column is for you.

Eric Evans
Domain Driven Design

I met Eric Evans in August of 2004, when his book had just came out and he was in Twin Cities at the Object Technology User Group (OTUG) talking about Ubiquitous Language, a language used by all team members to describe the domain model. I was very impressed with Eric's presentation. In very simple terms, he was able to find and explain the essence of what is often missing in domain implementations focused too much on technology.

You will not be disappointed with Eric's book. It describes patterns on how to explore a complex business domain and express it with a comprehensible software model. These patterns help me focus on central business problems while keeping the overall design of the systems understandable and manageable.

This is a must-read book for a business application designer and developer. Happy reading!