Beyond Technologies: Domain Driven Design - Factories and Repositories

Introduction

In this post I sum up the most important concepts about Domain Driven Design.

I recommend you when you read this post not to think in technologies. Put away the technical knowledge and think from an upper level, from an architectural level.

Encapsulating with FACTORIES

A FACTORY encapsulates the knowledge needed to create a complex object or AGGREGATE, which may itself have no responsibility in the domain model but is still part of the domain design. Provide an interface that encapsulates all complex assembly and that does not require the client to reference the concrete class of the objects being instantiated.

There are some PATTERNS to design FACTORIES

1. FACTORY METHOD

2. ABSTRACT FACTORY

3. BUILDER

Requirements for a FACTORY are:

§          Each creation method is atomic and enforces all invariants of the created object or AGGREGATE.

§          A FACTORY should only be able to produce an object in a consistent state.

§          For an ENTITY, this means the creation of the entire AGGREGATE, with all the invariants satisfied, but probably with optional elements still to be added.

§          For an immutable VALUE OBJECT, this means that all attributes are initialized to their correct final state. If the interface makes it possible to request an object that can not be created correctly, then an exception should be raised or some other mechanism should be invoked that will ensure that no improper return value is possible.

§          The FACTORY should be abstracted to the type desired, rather than the concrete classes created.

Accessing with REPOSITORIES

The goal of domain-driven design is to create better software by focusing on a model of the domain rather than the technology.

A REPOSITORY represents all objects of a certain type as a conceptual set. It acts like a collection, except with more elaborate querying capability. Objects of the appropriate type are added and removed, and the machinery behind the REPOSITORY inserts them or deletes them from the database.

Clients request objects from the REPOSITORY using query methods that select objects based on criteria specified by the client, typically the value of certain attributes. The REPOSITORY retrieves the requested object, encapsulating the machinery of database queries and metadata mapping. Repositories can implement a variety of queries that select objects based on whatever criteria the client requires.

A REPOSITORY lifts a huge burden from the client, which can now talk to a simple, intention-revealing interface, and ask for what it needs in terms of the model. To support all this requires a lot of complex technical infrastructure, but the interface is simple and conceptually connected to the domain model.

For each type of object that needs global access, create an object that can provide the illusion of an in-memory collection of all objects of that type. Set up access through a well-known global interface. Provide methods to add and remove objects, which will encapsulate the actual insertion or removal of data in the data store. Provide methods that select objects based on some criteria and return fully instantiated objects or collections of objects whose attribute values meet the criteria, thereby encapsulating the actual storage and query technology. Provide REPOSITORIES only for AGGREGATE roots that actually need direct access. Keep the client focused on the model, delegating all object storage and access to the REPOSITORIES.

REPOSITORIES have many advantages, including the following:

·         

          1. They present clients with a simple model for obtaining persistent objects and managing their life cycle.

2. They decouple application and domain design from persistence technology, multiple database strategies, or even multiple data sources.

3. The communicate design decisions about object access.

4. They allow easy substitution of a dummy implementation, for use in testing.

The REPOSITORY will delegate to the appropriate infrastructure services to get the job done.

Note: Leave the transaction control to the client who presumably has the context to correctly initiate and commit units of work. Transaction management will be simpler if the REPOSITORY keeps its hands off.

References

Eric Evans 2004. Domain Driven Design. Tackling Complexity in the Heart of Software. Addison-Wesley.

Beyond Technologies: Domain Driven Design - ENTITIES, VALUE OBJECTS, DOMAIN SERVICES AND AGGREGATES

Introduction

In this post I sum up concepts about Domain Driven Design:

§          Entities

§          Value Objects

§          Domain Services

§          Aggregates

I recommend you when you read this post not to think in technologies. Put away the technical knowledge and think from an upper level, from an architectural level.

ENTITY

An object defined primarily by its identity and not by their attributes. ENTITIES have life cycles that can change their form and content, but a thread of continuity must be maintained. Their class definitions, responsibilities, attributes, and associations should resolve around who they are, rather than the particular attributes they carry.

VALUE OBJECT

An object that represents a descriptive aspect of the domain with no conceptual identity and we care about only for what they are, not who or which they are.

VALUE OBJECTS are often passed as parameters in messages between objects. They are frequently transient, created for an operation and then discarded.

VALUE OBJECTS are used as attributes of ENTITTIES (and other VALUES).

DOMAIN SERVICES

There are important domain operations that can not find a natural home in an ENTITY or VALUE OBJECT. Some of these are intrinsically activities or actions, not things. Forcing the required domain functionality to be responsibility of ENTITY or VALUE either distorts the definition of a model-based object or adds meaningless artificial objects.

The name service emphasizes the relationship with other objects. Unlike ENTITIES and VALUE OBJECTS, it is defined purely in terms of what it can do for a client. A SERVICE tends to be named for an activity. A SERVICE should still have defined responsibility, and that responsibility and the interface fulfilling it should be defined as part of the domain model. Operations should come from the UBIQUITOUS LANGUAGE or be introduced into it. Parameters and results should be domain objects.

A DOMAIN SERVICE has three characteristics:

1.     1. The operation relates to a domain concept that is not a natural part of an ENTITY or VALUE OBJECT.

2.     2. The interface is defined in terms of other elements of the domain model.

3.     3. The operation is stateless.

SERVICES IN LAYERS

Application services: are the interface used by the outside world. These services could map outside messages to internal operations and processes, communicating with services in the Domain and Infrastructure layers to provide cohesive operations for outside clients.

Domain services: Embeds business rules. These use the infrastructure services to do their tasks.

Infrastructure services: communication with external resources like databases, file systems, web service end points, etc.

AGGREGATES

An AGGREGATE is a set of associated objects that we treat as a unit for the purpose of data changes. Each AGGREGATE has a root and a boundary.

§          The boundary defines what is inside the AGGREATE.

§          The root is a single, specific ENTITY contained in the AGGREATE. The root is the only member that outside objects are allowed to hold references to, although objects within the boundary may hold references to each other.

It is difficult to guarantee the consistency of changes to objects in a model with complex associations. Invariants are consistency rules that must be maintained whenever data changes and will involve relationships between members of the AGGREGATE. The invariants applied within an AGGREAGATE will be enforced with the completion of each transaction.

Rules for implementing AGGREGATES:

1. The root ENTITY has global identity and is ultimately responsible for checking invariants. ENTITIES other than root inside the boundary have local identity, unique only within the AGGREGATE, because no outside object can ever see it out of the context of the root ENTITY.

2.     2. Nothing outside the AGGREGATE boundary can hold a reference to anything inside, except to the root ENTITY.

3.     3. The root ENTITY can hand references to internal ENTITIES to other objects, but those objects can use them only transiently, and they may not hold on to the reference. The root may hand a copy of a VALUE OBJECT to another object, and it does not matter what happens to it, because it is a VALUE and no longer will have any association with the AGGREGATE.

4.     4. Only AGGREGATE roots can be obtained directly with database queries. All other objects must be found by traversal of associations.

5.     5. Objects within the AGGREGATE can hold references to other AGGREGATE roots.

6.     6. A delete operation must remove everything within the AGGREGATE boundary at once.

7.     7. When a change to any object within the AGGREGATE boundary is committed, all invariants of the whole AGGREGATE must be satisfied.  

Example - Bank Customer

References

Eric Evans 2004. Domain Driven Design. Tackling Complexity in the Heart of Software. Addison-Wesley.