The Domain Model pattern is useful when dealing with complex business logic. A popular design methodology that utilizes the Domain Model pattern is known as DDD. In a nutshell, DDD is a collection of patterns and principles that aid in your efforts to build applications that reflect an understanding of and meet the requirements of your business. Outside of that, it’s a whole new way of thinking about your development methodology. DDD is about modeling the real domain by first fully understanding it and placing all the terminology, rules, and logic into an abstract representation within your code, typically in the form of a domain model.You will take a look at the main aspects of DDD because this is the methodology that is used for the majority of exercises in the remainder of this book.The Ubiquitous language The notion of a ubiquitous language is that it should act as a common vocabulary that is used by developers, domain experts, and anyone else involved in a project to describe the domain. A domain expert is someone with the knowledge and skills in a particular domain who will work closely with you as you develop the domain model to ensure that you fully understand the business model before trying to represent it in code. In the example of a loan application, this could be an underwriter. Through listening to this person, you will build a vocabulary of all terminology used during the process of approving a loan. Your class, methods, and property names should all be based around the same ubiquitous language. This enables you to talk to domain experts about code in a language that they understand; also, new developers working on the code should get a good grounding in what the domain is really all about. It will also enable them to talk to business experts about the smallest details of complex business logic with relative ease. When all parties involved in the development of an application are speaking the same language, problems and solutions can be conveyed easily, making the application quicker and easier to build.
DDD is not a framework, but it does have a set of building blocks or concepts that you can incorporate into your solution. The following sections introduce these concepts one at a time.
entities
Entities are the things discussed previously in the Domain Model section, such as an order, customer, and product in an e-commerce site and a blog, and post objects in a blogging application. They encompass the data and behavior of the real entity in an abstract manner. Any logic pertaining to an entity should be contained within it. Entities are the things that require an identity, which will remain with it throughout its lifetime. Consider a borrower in terms of a loan application; a borrower has a name, but names can change and can be duplicated, so you need to add a separate identity that will stay with the borrower through its life in the loan application regardless of a name, job, or address change. Typically, a system uses some kind of unique identifier or auto-numbering value for any entities that don’t have a natural way to identify them. Sometimes entities do have natural keys, such as a Social Security number or an employee number. Not all the objects in your domain model are unique and require an identity. For some objects, it’s the data that is of most importance, not identity; these objects are called value objects.
Value objects
Value objects have no identity; they are of value because of their attributes only. Value objects generally don’t live on their own; they are typically, but not always, attributes of an entity. If you cast your mind back to the simple Bank Account application that you worked on in the Domain Model, you remember that the Transaction object had no identity because it exists only in terms of the Bank Account that it is associated with; it is a value object because, in this context, it doesn’t exist on its own. aggregates and aggregate roots
Big systems or complex domains can have hundreds of entity and value objects, which have complex relationships. The domain model needs a method of managing these associations; more importantly, 92 ❘ chaPTer 4 The BuSineSS logic layer: organizaTionlogical groups of entities and value objects need to define an interface that lets other entities work with them. Without such a structure, the interaction between groups of objects can be confusing and lead to problems later.
The notion of an aggregation groups logical entities and value objects. From the DDD definition, an aggregate is simply “a cluster of associated objects that are treated as a unit for the purpose of data changes.” The aggregate root is an entity, which is the only member of the aggregate that any object outside the aggregate is allowed to hold a reference to. The idea of an aggregate exists in DDD to ensure data integrity within the domain model. An aggregate root is a special entity that acts as the logical way into the aggregate. For example, if you take an order in the context of an e-commerce shop, you can regard it as the aggregate root, because you only want to be able to edit an order line or apply a voucher by going through the root of the aggregate—that is, the order entity. This enables complex object graphs to remain consistent and business rules to be adhered to. So, instead of an order just exposing a collection of vouchers issued against it through a simple List property, it can have methods with complex rules that enable vouchers to be applied to it and expose the list of vouchers as a read-only collection for display purposes.
Domain services
As you saw in the Domain Model Pattern Bank Account exercise, the BankAccountService class contained the logic to transfer funds between two bank accounts. Methods that don’t really fit on a single entity or require access to the repository are contained within domain services. The domain service layer can also contain domain logic of its own and is as much part of the domain model as entities and value objects.
application services
The Application service is a thin layer that sits above the domain model and coordinates the application activity. It does not contain business logic and does not hold the state of any entities; however, it can store the state of a business workflow transaction. You use an Application service in the Domain Model Bank Account exercise to provide an API into the domain model using the Request-Reply messaging pattern.
repository
The Repository pattern, which you will examine in more detail in Chapter 7, acts as an in-memory collection or repository for business entities, completely abstracting away the underlying data infrastructure. This pattern allows you to keep your domain model free of any infrastructure concerns, making it POCO and PI.
layering
Layering is an important concept in DDD because it helps to enforce the separation of concerns. Figure 4-7 shows a graphical representation of the layers and concepts that make up DDD; however, I should stress that DDD is much more about your mindset when developing complex business applications than how you set up your solution.
