Entity

<p>
    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.</p>
<p>
    Database entity is a table, it's identity is key.</p>
<p>
    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"</p>
<ul>
    <li>
        <p>
            It run though times</p>
        <p>
            This means after close the application, and start a new application, an object(entity)
            can still be reconstructed.</p>
    </li>
    <li>
        <p>
            It run across distinct represenations</p>
        <p>
            This means the same object can be consturcted in different machine, or different
            software</p>
    </li>
</ul>
<p>
    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.
</p>
<p>
    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.
</p>
<p>
    How what is an idenitity in domain model?
</p>
<ol>
    <li>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. </li>
    <li>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.</li>
    <li>Focus on identity by building each entity with some mechanism for defining uniqueness.
    </li>
</ol>
<h1>
    Value Objects</h1>
<p>
    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.
</p>
<h1>
    Aggregates</h1>
<p>
    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.
</p>
<p>
    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 <b>database</b>.
    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 <b>object world</b>,
    we should <b>forget</b> 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 <b>value objects</b> such as Seats and Tires, and can also have
    other <b>entity objects</b> 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.</p>
<h1>
    Services</h1>
<p>
    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.
</p>
<blockquote>
    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
</blockquote>
<p>
    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 <b>reusable</b>.
</p>
<p>
    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.</p>
<h1>
    Domain Model
</h1>
<blockquote>
    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</blockquote>
<p>
    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.
</p>
<p>
    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.</p>
<p>
    Now, give this team a robust <b>domain model</b> 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.
</p>
<p>
    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.
</p>