Search in book...
Toggle Font Controls
Create new playlist

Name your new playlist

Playlist description (optional)
Sign In

Email address

Password

Forgot Password?

or

Continue with Facebook

Continue with Google
Sign Up

Full Name

Email address

Confirm Email Address

Password

or

Continue with Facebook

Continue with Google

14
Introducing the Domain Modeling Building Blocks

WHAT’S IN THIS CHAPTER?

The role of tactical patterns in creating an effective object-oriented domain model
Introducing value objects, entities, domain services, and modules to model your domain and behaviors
An overview of the lifecycle patterns: aggregate, factory, and repository
The emerging patterns of event sourcing and domain events

Wrox.com Code Downloads for this Chapter

The wrox.com code downloads for this chapter are found at www.wrox.com/go/domaindrivendesign on the Download Code tab. The code is in the Chapter 14 download and individually named according to the names throughout the chapter.

Mapping the implementation model back to the analysis model and ensuring they are bound to one another is hard. To guide developers and clarify designs, Evans has built upon the domain model pattern that was first catalogued in Martin Fowler’s book Patterns of Enterprise Application Architecture. He introduces a pattern language containing a number of building block patterns to enable the creation of effective domain models. The patterns, built around best-practice, object-oriented techniques, are sometimes referred to as the tactical patterns of Domain-Driven Design (DDD). Many of the patterns themselves are not new, but Evans was the first to group them in this manner as an aid for developers to create effective domain models. This chapter gives a high-level introduction to the tactical building block patterns of Domain-Driven Design. Each pattern has its own chapter in this part of the book where it is covered in more detail.

Although this chapter and the rest of this part detail techniques for creating domain models, the implementation tactics for building domain models should remain flexible and open to innovation. Evans’s original text favored an object-oriented approach, but don’t overlook the different modeling paradigms, as discussed in Chapter 5, “Domain Model Implementation Patterns.” The domain events pattern, which you will read about later in this chapter, was not included in the original building blocks, something that Evans recently said he regretted. In addition, functional programming and event sourcing (covered in Chapter 18, “Domain Events”) are becoming popular ways to express domain models.

The patterns used to create domain models and tie implementation to analysis have continually evolved since Evans’s original text. The semantics of how you create domain models can and will change, what is important is to represent concepts in code using the language of the domain—the Ubiquitous Language.

Tactical Patterns

The role of the tactical patterns in DDD is to manage complexity and ensure clarity of behavior within the domain model. You use the patterns to capture and convey meaning, relationships, and logic within the domain. The patterns are built around solid object-oriented principles, and many are catalogued in widely regarded design books, namely Patterns of Enterprise Application Architecture, by Martin Fowler, and Design Patterns: Elements of Reusable Object-Oriented Software, by Ralph Johnson, John Vlissides, Richard Helm, and Erich Gamma.

Each building block pattern is designed to have a single responsibility; it could be to represent a concept in the domain like an entity or a value object, or it could be to ensure that the concepts of the domain are kept uncluttered from lifecycle concerns like the factory or repository objects. In a way, you can view the building blocks as a ubiquitous language (UL) for developers to use as a framework for constructing rich and useful domain models.

You can use numerous building block patterns, shown in Figure 14.1, in the creation of a domain model. Note that the application services pattern is a client of the domain model and is therefore not covered in this part of the book. Application services are covered in Chapter 25, “Commands: Application Service Patterns for Processing Business Use Cases.”

images — **FIGURE 14.1** Tactical patterns—domain model building blocks.

Patterns to Model Your Domain

The following patterns represent the policies and logic within the problem domain. They express relationships between objects, model rules, and bind the detail of the analysis model to the code implementation model. These are the patterns that express the elements of your model in code.

Entities

An entity represents a concept in your domain that is defined by its identity rather than its attributes. Although an entity’s identity remains fixed throughout its lifecycle, its attributes may change. An entity is responsible for defining what it means to be the same; in code this is often achieved by overriding the equality operations of a class.

An example of an entity is a product; its unique identity won’t change once it is set but its description, price, etc., can be altered many times. Entities are mutable as the attributes can change.

Figure 14.2 shows the main concepts of an entity.

In Listing 14-1, you see a product modeled as an entity.

LISTING 14-1: A Product Entity


public class Product : Entity<Guid>
{
    private readonly IList<Option> _options;
    private Price _selling_price;
    private Price _retail_price;

    public Product(Guid id, Price sellingPrice, Price retailPrice)
        : base(id)
    {
        _selling_price = sellingPrice;
        if (!selling_price_matches(retailPrice))
            throw new PricesNotInTheSameCurrencyException(
                "Selling and retail price must be in the same currency");
        _retail_price = retailPrice;
        _options = new List<Option>();
    }

    public void change_price_to(Price new_price)
    {
        if (!selling_price_matches(new_price))
            throw new PricesNotInTheSameCurrencyException(
                "You cannot change the price of this
                  product to a different currency");
        _selling_price = new_price;
    }

    public Price savings()
    {
        Price savings = _retail_price.minus(_selling_price);

        if (savings.is_greater_than_zero())
            return savings;
        else
            return new Price(0m, _selling_price.currency);
    }

    private bool selling_price_matches(Price retail_price)
    {
        return _selling_price.Equals(retail_price);
    }

    public void add(Option option)
    {
        if (!this.contains(option))
            _options.Add(option);
        else
            throw new ProductOptionAddedNotUniqueException(
                string.Format(
                  "This product already has the option {0}",
                  option.ToString()));
    }

    public bool contains(Option option)
    {
        return _options.Contains(option);
    }
}

Listing 14-1 shows that the identifier of a product is set on construction and there are no methods to change it. The Product entity delegates all work to the Money and Option value objects—the attributes/characteristics of the Order. The product entity encapsulates data and exposes behavior; the data of the class is hidden.

You will also have noticed that the entity has a generic base class that takes the type used for identification. Within the base class are the overridden equality methods, similar to what you saw in the Money value object. However, this time when comparing objects, you compare the type and the ID.

For completeness, Listing 14-2 shows the implementation of the Entity base class.

LISTING 14-2: Entity Base Class


public abstract class Entity<TId> : IEquatable<Entity<TId>>
{
    private readonly TId id;

    protected Entity(TId id)
    {
        if (object.Equals(id, default(TId)))
        {
            throw new ArgumentException(
                "The ID cannot be the default value.","id");
        }

        this.id = id;
    }

    public TId Id
    {
        get { return this.id; }
    }

    public override bool Equals(object obj)
    {
        var entity = obj as Entity<TId>;
        if (entity != null)
        {
            return this.Equals(entity);
        }
        return base.Equals(obj);
    }

    public override int GetHashCode()
    {
        return this.Id.GetHashCode();
    }

    public bool Equals(Entity<TId> other)
    {
        if (other == null)
        {
            return false;
        }
        return this.Id.Equals(other.Id);
    }
}

Listing 14-2 shows that by inheriting from this base class, you keep the logic that determines equality between entities within the entity itself. The abstract base class keeps all the noise of identity and equality checking out of the implementation class so that it can focus on business logic.

Value Objects

Value objects represent the elements or concepts of your domain that are known only by their characteristics; they are used as descriptors for elements in your model; they do not require a unique identity. Because value objects have no conceptual identity within the model, they are defined by their attributes; their attributes determine their identity. Value objects don’t need identity because they are always associated with another object and are therefore understood within a particular context. For instance, you may have an order entity that uses value objects to represent the order shipping address, items, courier information, and so on. Not one of these characteristics needs identity itself because it only has meaning within the context of being attached to an order. An order address that is not attached to an order does not have meaning. Value objects are comparable based on their attributes, and like entities are responsible for any equality checks.

Because they are defined by their attributes, value objects are treated as immutable; that is, once constructed, they can never alter their state. A good example of a value object is money. It doesn’t matter that you can’t distinguish between the same five one pound coins or one dollar bills in your pocket. You don’t care about the currency’s identity—only about its value and what it represents. If somebody swapped a five dollar bill for one you have in your wallet, it would not change the fact that you still have five dollars. Of course, in real life, money can have a unique identifier in the form of a serial number, but the domain model does not reflect real life. Instead, it is an abstraction of it built to fulfill the needs of use cases within the problem domain. Figure 14.3 shows the main concepts of a value object.

Listing 14-3 shows money modeled as a value object.

LISTING 14-3: A Money Value Object


public class Money
{
    protected readonly decimal _value;
    private readonly Currency _currency;

    public Money()
        : this(0m, new SterlingCurrency())
    {
    }

    public Money(decimal value, Currency currency)
    {
        _value = value;
        _currency = currency;
    }

    public Money add(Money to_add)
    {
        if (this._currency.Equals(to_add._currency))
            return new Money(_value + to_add._value, _currency);
        else
            throw new NonMatchingCurrencyException(
                "You cannot add money with different currencies.");
    }

    public Money minus(Money to_discount)
    {
        if (this._currency.Equals(to_discount._currency))
            return new Money(_value - to_discount._value, _currency);
        else
            throw new NonMatchingCurrencyException(
                "You cannot remove money with different currencies.");
    }

    public override string ToString()
    {
        return string.Format("{0}",
            _currency.format_for_displaying(_value));
    }

    // Equality overrides

    public static bool operator ==(Money money, Money money_to_compare)
    {
        if ((object)money == null)
        {
            return (object)money_to_compare == null;
        }

        return money._value == money_to_compare._value &&
                money._currency == money_to_compare._currency;
    }

    public static bool operator !=(Money money, Money money_to_compare)
    {
        return (money._value != money_to_compare._value ||
                money._currency != money_to_compare._currency);
    }

    public bool Equals(Money obj)
    {
        if (obj == null) return false;
        return obj._value == _value && obj._currency.equals(_currency);
    }

    public override bool Equals(System.Object obj)
    {
        if (obj == null) return false;
        if (obj.GetType() != this.GetType()) return false;

        return ((Money)obj)._value == _value &&
                           obj._currency.equals(_currency);
    }

    public override int GetHashCode()
    {
        return (_value.GetHashCode() + _currency.GetHashCode())
                           .GetHashCode();
    }
}

As you can see from Listing 14-3 the equality methods have been overridden, meaning that the Money object is compared only by its attributes; in this instance, the attributes are the value and the currency. The money class is immutable. Once it has been created, it cannot change state. The add method returns a new instance of a Money object. This is known as closure of operations because you are not altering the state of the original money object. Another value object is used to capture the concept of currency. You delegate to the currency object when comparing equality. Again, the equality methods have been overridden.

Domain Services

Domain services encapsulate domain logic and concepts that are not naturally modeled as value objects or entities in your model. Domain services have no identity or state; their responsibility is to orchestrate business logic using entities and value objects. A good example of a domain service is a shipping cost calculator as shown in Listing 14-4. This service is a business function that, given a set of consignments (value objects) and a collection of weight bandings, can calculate the cost of shipping. This functionality does not sit comfortably on a domain object, so it is better represented as a domain service.

LISTING 14-4: A Domain Service Shipping Cost Calculator


    public class ShippingCostCalculator
    {
        private IEnumerable<WeightBand> _weightBand;
        private readonly WeightInKg _boxWeightInKg;

        public ShippingCostCalculator(IEnumerable<WeightBand> weightBand,
                                      WeightInKg boxWeightInKg)
        {
            _weightBand = weightBand;
            _boxWeightInKg = boxWeightInKg;
        }

        public Money CalculateCostToShip(IEnumerable<Consignment> consignments)
        {
            var weight = GetTotalWeight(consignments);
            // Reverse sort list
            _weightBand = _weightBand.OrderBy(x =>
                    x.ForConsignmentsUpToThisWeightInKg.Value);

            // Get first match
            var weightBand = _weightBand.FirstOrDefault(x =>
                    x.IsWithinBand(weight));

            return weightBand.Price;
        }

        private WeightInKg GetTotalWeight(
                        IEnumerable<Consignment> consignments)
        {
            var totalWeight = new WeightInKg(0m);

            // Calculate the weight of the items
            foreach (Consignment consignment in consignments)
                totalWeight = totalWeight.Add(consignment.ConsignmentWeight());

            // Add a box weight
            totalWeight = totalWeight.Add(_boxWeightInKg);

            return totalWeight;
        }
    }

The ShippingCostCalculator encapsulates the domain logic that calculates the shipping cost of consignment based on the weight of a collection of consignments, along with the weight of a box. By organizing this logic under a specific domain service and naming it, you can explicitly talk to domain experts about a particular piece of domain logic such as a policy or a process in a concise manner. The ShippingCostCalculator may have been an implicit concept held by the business, but by naming it, you have ensured it is now explicit and should be added to the UL and the analysis model.

Modules

Modules in C# are implemented as namespaces or projects. You use them to organize and encapsulate related concepts (entities and value objects) so you can simplify your understanding of larger domain models. Modules are used to decompose the domain model. Don’t confuse them with subdomains that decompose the domain and bounded contexts that delimit the applicability of a domain model. As shown in Figure 14.4, module names are lifted straight from the UL and enable distinct parts of the domain model to be understood in isolation. Modules enable developers to quickly read and understand a domain model in code before digging deep into class files. They also act as a responsibility boundary, clearly defining parts of the domain model and ensuring that relationships between domain objects are kept to a minimum. Apply modules to promote low coupling and high cohesion within your domain model. Try limiting the contents of a module to a cohesive set.

LifeCycle Patterns

The following patterns deal with the creation and persistence of the objects that represent the structure of the domain.

Aggregates

Entities and value objects collaborate to form complex relationships that meet invariants within the domain model. When dealing with large interconnected associations of objects, it is often difficult to ensure consistency and concurrency when performing actions against domain objects. Figure 14.5 shows a large object graph. Trying to treat this collection of objects as one conceptual whole is difficult and could result in performance problems for an application. For example we would not want to block a customer updating an address on her account just because an earlier order’s status is being changed at the same time. These two things are unrelated and need not share a consistency or concurrency boundary.

Domain-Driven Design has the Aggregate pattern to ensure consistency and to define transactional concurrency boundaries for object graphs. Large models are split by invariants and grouped into aggregates of entities and value objects that are treated as a conceptual whole. As shown in Figure 14.6, you can distill the model into aggregates.

Relationships between aggregate roots should be implemented by keeping a reference to the ID of another aggregate root and not a reference to the object itself, as shown in Figure 14.7. This principle helps to keep a boundary between aggregates and avoids the need to load large object graphs that are not required.

The aggregate groupings in Figure 14.6 and 14-7 at first glance look like a reasonable way to split the object graph; however, defining aggregate groups based purely on related concepts only goes some way to improve consistency and concurrency challenges. Take the customer aggregate, if an address is amended at the same time that some personal details of a customer are changed we could introduce blocking issues. These two concepts although related to a customer do not require an invariant. Therefore, we can split these into two separate aggregates and use this same logic for a credit card, then group them all under a customer module, as can be seen in Figure 14.8.

An aggregate root, shown in Figure 14.9, acts as the entry point into the aggregate. No other entity or value object outside of the aggregate can hold a reference to an object within the aggregate. Objects outside the aggregate can only reference the aggregate root of another aggregate. Any changes to objects in the aggregate need to come through the root. The root encapsulates the data of the aggregate and only exposes behaviors to change it.

Factories

If the creation of an entity or a value object is sufficiently complex, you should delegate the construction to a factory. A factory ensures that all invariants are met before the domain object is created. If a domain object is simple and has no special rules for valid construction, favor a constructor method over a factory object. You can also use factories when re-creating domain objects from persistent storage.

In Listing 14-5, you see that a Customer entity has a factory method to enable an address to be created with a valid customer ID.

LISTING 14-5: A Factory Method on an Entity


public class Customer : Entity<Guid>
{
    public Customer(Guid id)
        : base(id)
    {
    }

    // ...

    public Address create(Address delivery_address)
    {
        return new Address(Guid.NewGuid(), this.Id);
    }
}

Repositories

A domain model needs a method for persisting and hydrating an aggregate. Because an aggregate is treated as an atomic unit, you should not be able to persist changes to an aggregate without persisting the entire aggregate. A repository, as shown in Figure 14.11, is a pattern that abstracts the underlying persistence store from the model allowing you to create a model without thinking about infrastructure concerns. The repository is the mechanism that you should use to retrieve and persist aggregates. For view rendering, a repository is not required, and querying against a data store is the most efficient method for reporting needs. A repository is an infrastructure concern, so it is not always necessary to abstract away the underlying framework doing all the hard work. It can be more worthwhile to lean on ORM (Object Relational Mapper) frameworks to act as a repository; examples include NHibernate, RavenDB, and Entity Framework. Many developers get hung up on this pattern. Think of it simply as a method of persistence and rehydration. Treat it like infrastructure, and don’t get hung up on abstracting it away.

Emerging Patterns

Since Eric Evans’ original text, two patterns have emerged that are useful for creating domain models. Namely the domain events pattern, covered in Chapter 18, and the event sourcing pattern, covered in Chapter 22 (“Event Sourcing”).

Domain Events

Domain events signify something that has happened in the problem domain that the business cares about. You can use events to record changes to a model in an audit fashion, or you can use them as a form of communication across aggregates. Often an operation on a single aggregate root can result in side effects that are outside the aggregate root boundary. Other aggregates within the model can listen for events and act accordingly.

For example, consider the basket within an e-commerce site, as shown in Figure 14.12. Every time a customer places an item in a basket, it’s important to update the recommended products that are displayed on the site. In this scenario, after a domain event is raised with details of the basket, a customer’s recommendations are modified. The event is subscribed to by the recommendation’s bounded context. Without using a domain event, you need to explicitly couple the basket bounded context to the recommendation context. Domain events give a more natural flow of communication and focus on the when.

In Listing 14-6, you see a domain event being published from a basket.

LISTING 14-6: Domain Events being raised on a basket entity


namespace Domain.Shopping
{
    public class Basket
    {
        private BasketItems _items;
        private Guid _id;

        // ....

        public void add(Product product)
        {
            _items.Add(BasketItemFactory.CreateItemFor(product, this));

            DomainEvents.raise(new ProductAddedToBasket(this._id,
                                     _items.ids_of_items_in_basket()));
        }
    }

    public class ProductAddedToBasket
    {
        public Guid basket_id { get; private set; }
        public IEnumerable<Guid> items_in_basket { get; private set; }

        public ProductAddedToBasket(Guid basket_id,
                                    IEnumerable<Guid> items_in_basket)
        {
            basket_id = basket_id;
            items_in_basket = items_in_basket;
        }
    }

    // .....
}

In Listing 14-7, you see a recommendation service handling the event raised by the basket.

LISTING 14-7: A Domain Event Handler


namespace Domain.Recommendations
{
    public class RecommendationsEventHandlers
    {
        // ......

        public void Handle(Shopping.ProductAddedToBasket product_added)
        {
            _recommendation_service.update_suggestions_for(
                product_added.basket_id, product_added.items_in_basket);
        }
    }
}

Don’t worry too much about the syntax of the code at this stage; it is covered in Chapter 18. Domain events play a crucial role in the code.

Event Sourcing

A popular alternative to traditional snapshot-only persistence is event sourcing. Instead of storing the state of an entity in a database, you store the series of events that lead up to the state. Storing all of the events increases the analytical capabilities of a business. Instead of just asking what the current state of an entity is, a business can ask what the state was at any time in the past, as shown in Figure 14.13.

Being able to query the state of your domain model at any time in the past provides a competitive business advantage because you can correlate events that have occurred in the real world with changes to the state of your domain model. Online travel agents may want to investigate why the number of bookings had a massive dip in a certain month. With event sourcing, they can rebuild the state of their catalog and re-run the searches that their users made to understand why those users did not find a vacation they wanted.

As a DDD practitioner, not only is your responsibility to suggest the possibility of using event sourcing to the business, but you also have to learn new ways of modeling your domain to support event sourcing. In particular, you need to move away from dumping an entity’s state into a database using an ORM. Instead, you need to find a way of modeling, capturing, and persisting domain events. You may even need to add event store functionality to an existing database. All of these concerns are covered in detail in Chapter 22.

The Salient Points

The tactical patterns of DDD are Evans’s building blocks based on Martin Fowler’s patterns for use when creating an Object-Oriented Domain model.
The building blocks are guides to creating effective domain models, but they are only guides. The way you implement domain models can vary greatly, so don’t get too hung up on the building block patterns.
Entities
- Are defined by their identity.
- Identity remains constant throughout its lifetime.
- Are responsible for equality checks.
Value Objects
- Describe the properties and characteristics within the problem domain.
- Have no identity.
- Are immutable, meaning that they cannot be changed. Instead properties modeled as value objects must be replaced.
Domain Services
- Contain domain logic that can’t naturally be placed in an entity or value object, whereas application services orchestrate the execution of domain logic but don’t actually implement it.
- Have no internal state, so you can call it repeatedly with the same input, and it always gives the same output.
Modules
- Are used to decompose, organize, and increase the readability of the domain model.
- Namespaces, an implementation of modules, can be applied to reduce coupling and increase cohesion within the domain model.
- Enable readers to quickly understand the design of a model.
- Help to define clear boundaries between domain objects.
- Encapsulate concepts that can be understood independently of each other. They operate on a higher level of abstraction than aggregates and entities.
Aggregates
- Decompose large object graphs into small clusters of domain objects to reduce the complexity of the technical implementation of the domain model.
- Represent domain concepts, not just generic collections of domain objects.
- Are based around domain invariants.
- Are a consistency boundary to ensure the domain model is kept in a reliable state.
- Ensure transactional concurrency boundaries are set at the right level of granularity to ensure a usable application by avoiding blocking at the database level.
Factories
- Separate use from construction.
- Encapsulate complex entity and value object construction.
Repositories
- Expose the interface of an in-memory collection of aggregate roots.
- Should not be used for reporting.
- Provide the retrieval and persistence needs of aggregate roots.
- Decouple the domain layer from database strategies and infrastructure code.
Domain Events
- Are significant occurrences in the real-world problem domain that business users care about; they are part of the ubiquitous language (UL).
- Are an emerging design pattern that makes domain events more explicit in code.
- Are akin to publish-subscribe, where events are raised and event handlers handle them.
Event Sourcing
- Replaces traditional snapshot-only storage with a full history of events that produce the current state.
- Allows powerful querying capabilities that revolve around time, known as temporal queries.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.