<h1>
    Inherit from a certain base class (besides the object)</h1>
<p>
    A common pattern in ORM solutions is to force consumers to inherit from a provider-specific
    base class. The reason for this is dependent on the provider, but typically the
    base class has some sort of attribute or method required for persistence. This is
    not a significant problem if you’re designing a system from the ground up, but if
    you already have a domain model and you’re trying to add persistence, this can be
    a pain because .NET supports only single inheritance.</p>
<h1>
    Instantiate only via a provided factory</h1>
<p>
    Domain Driven theory supports the use of factories when building domain models.
    We don’t want to have to use a provider-specific factory implementation to create
    our persistent classes. This couples our model to the ORM instead of keeping it
    independent, and is usually required by ORM solutions for object tracking and notifications.</p>
<h1>
    Use specially provided data types, such as for collections</h1>
<p>
    This is another pretty typical situation that you’ll see in ORM tools in order for
    them to provide functionality for out-of-the- box lazy loading. This is so common
    in the ORM solution world that it doesn’t bother me too much, because you can usually
    design around this functionality to keep your model independent. However, I can
    understand the desire to have this as a feature of your ORM.</p>
<h1>
    Implement a specific interface</h1>
<p>
    Similar to base class inheritance, this is another situation in which the ORM engine
    needs a specific implementation in the persistent classes to do its job. This is
    obviously a better design, to have to implement an interface instead of having to
    use up your only class inheritance option in .NET, but you are still tightly coupling
    your domain model to the ORM, making it less portable.</p>
<h1>
    Provide specific constructors
</h1>
<p>
    This is common in ORM solutions so the engine can create instances of your domain
    model type or reconstitute a particular value. My personal opinion is that having
    to implement a default constructor doesn’t really violate any major design law.
    However (and I have yet to see an example this), anything beyond the default constructor
    implementation would be a significant irritation.</p>
<h1>
    Provide mandatory specific fields:</h1>
<p>
    Providing specific types on fields (for example, a GUID for an ID) is sometimes
    mandatory in ORM frameworks. This is often part of an interface or a base class
    implementation, and is required in many cases for handling associations and relationships.</p>
<h1>
    Avoid certain constructs and forced usage of certain constructs
</h1>
<p>
    This criterion can consist of a forced access modifier on a field or method or can
    be the metadata used for mapping. A good example of this is using get and set functions
    as you might in Java versus a property in C#. Additionally, as you will see later,
    this can also be the use of .NET attributes in your model. Attributes, extraneous
    methods, base classes, and so forth are a big concern of mine when developing a
    domain model because I don’t like having to change my well-thought- out access modifiers
    or pollute my model with some garbage in order for the persistence engine to work.
</p> 

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