Another Notes of DDD

Entity

Real word entity is an independent, seperate, or self-contained existence. It's identity is what gives it uniqueness and differentiates it from other thing else. This is typically a set of characteristics or traits that defines what it is.

Database entity is a table, it's identity is key.

Software identity is representation of a real world identity. But it is not a business object. It is not an extension of database entity, although they have some relevance. It is a modeling effort. According to Evans, the entity is an object that is defined by a "thread of identity that runs though time and often across distinct representations"

• It run though times

  This means after close the application, and start a new application, an object(entity) can still be reconstructed.

• It run across distinct represenations

  This means the same object can be consturcted in different machine, or different software

If we find the need to identity an object which runs through the time and across distinct represenation, we need to define it as an entity.

But what exactly is an identity for software entity? In real life, how can people identify me? In real life, I am entity. Although I have an social security number, people do not use it to call identify me. They identify me by name. May be somebody has the same name as me, but they can still identity me, because I still have other fact which is different, for example, my job, my height, color or what ever.

How what is an idenitity in domain model?

1. Not every object in your domain model is an entity, and therefore our framework must have the capability to evaluate the identity of multiple different objects. This is typically done through comparison operations and by overriding equals, and it is necessary to promote a healthy existence.
2. Ensure that our entity objects have stability throughout their life cycle. This is largely controlled by the ORM tool; however, it is important to keep stability in mind when using transactions and developing your model.
3. Focus on identity by building each entity with some mechanism for defining uniqueness.

Value Objects

Evans says, "When you care only about the ttributes of an element of the model, classify it as a value object." We can think of value object as an object that cannot exist on its own, an object that has no identity by itself. For all intents and purposes, value objects are the parasites of your model because there is no reason or their existence except to describe and associate themselves with our entities. Most of the time, we shouldn’t assign or track their identity for value objects or you will likely impair system performance. These objects are used to describe aspects of the system and so they should, in most cases, be treated as immutable.

Aggregates

According to Merriam-Webster Online, an aggregate is “formed by the collection of units or particles into a body, mass, or amount.” Aggregates, in terms of the domain model, are just that: a logical grouping of entities and value objects into a collection. The reason for aggregation in your model is that complex relationships can lead to data inconsistencies in your application and database.

This concept is simple: the more moving parts in your model, the more likely you are to end up with problems. A case in point is the cleanup of orphaned data and objects. Say, for example, that you have an account record in your database. If you delete the account, you can use a cascading delete to ensure that you don’t have any orphaned data hanging out in other related tables. In the object world, we should forget about the database concept like primary kye, foreign key, cascading update/reference. We need to create aggregate to prevent memory leaking or data store corruption. Our Automobile entity, is the perfect example of an aggregate. The automobile has value objects such as Seats and Tires, and can also have other entity objects such as the Owner object. By this account, the Automobile object becomes the source of the aggregate and for all intents the owner of the group. You may be asking yourself how this helps to enforce referential integrity in your model. The answer actually lies in the structure of your domain model and the objects you expose to consumers. By controlling what objects a consumer can create and by exposing the aggregate, you can ensure integrity in your model. The most common way to enforce this technique is to use the factory pattern discussed later in this chapter and demonstrated in detail in Chapter 8. However, a solid understanding of accessibility modifiers and a well-laid-out hierarchy will also be critical to ensure integrity.

Services

Not everything in our model can be classified as an entity or a value object. Typically in our domain model, a service will be developed as an action or an activity, which doesn’t make sense to build into our entities or value objects.

Some concepts from the domain aren’t natural to model as objects. Forcing the required domain functionality to be the responsibility of an Entity or Value either distorts the definition of a model-based object or adds meaningless artificial objects. - Eric Evans

Continuing with the automobile example, suppose the automobile informs you when it is time to change oil. This service requires the evaluation of a series of domain objects and thresholds to determine that it is time for an oil change. Although the service is expressed by using Automobile entity (technically an aggregate), it wouldn’t make sense to encapsulate it as that object. This service interface needs to be outside the entity and value to keep it reusable.

Service does not only reside in domain layer, it can also reside in other layer such as application, infrastructure. Service is a natual object concept, its purpose is to build functions in as much reusability as possible, and encapsulate outside the implementation of our value and entity objects.

Domain Model

At its worst, business logic can be very complex. Rules and logic describe many different cases and slants of behavior, and it’s this complexity that objects were designed to work with. A Domain Model creates a web of interconnected objects, where each object represents some meaningful individual, whether as large as a corporation or as small as a single line on an order form. —Martin Fowler

The domain model is much more than just an object model because its creation is rooted in the collaboration among the experts in the organization. Specifically, the domain model is the conceptual layer that can be used to represent the process as a whole and is fundamentally a mechanism that can bring the people in the software life cycle closer together. Similar to UML acting as a common vocabulary, a completed domain model can also be a catalyst for enhanced cross-process and cross-functional communication.

As an example, take Company X, comprising a handful of new developers, a few senior developers, some quality control people, a couple of business analysts, and a project manager (in other words, a rather typical development team). Suppose that the developer and business analysts have a hard time getting anything done because the developers don’t really understand the nuances of banking and likewise the business analysts can’t explain things effectively to the technical personnel. To overcome these communication problems, Company X has implemented a Software Development Life Cycle (SDLC) process, involving reams of paper defining specific problems and development needs for the current system. The quality control (QC) people resent the developers because the developers have never adequately explained the situation from an impact standpoint, and the project manager is frustrated because the communication issues are reducing the time he is able to spend on the golf course.

Now, give this team a robust domain model that conceptualizes the realm of interactions in the software, and many of these communication issues disappear. The UML (or any common modeling language) used to diagram the domain is a common way for everyone to communicate. The domain model itself can be used to explain complex interactions from a functional and a technical perspective.

When you are working on modeling a business domain, don’t get hung up on formalized UML in meetings with the domain experts. The UML should not become an obstacle in development. Instead, it should help people communicate by using a common lexicon. The easiest way to build a good domain model is with paper and pencil or a whiteboard. We can use rudimentary notation that everyone can understand, demonstrating the relationships and behavior within the model. After the initial meetings, we take the whiteboard drawing and use a formal modeling tool and add any formal notation that we may have glossed over in the meeting.