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

21
Repositories

WHAT’S IN THIS CHAPTER?

The role and responsibilities of the repository pattern
The misunderstandings of the repository pattern
The difference between a domain model and a persistence model
Strategies for persisting your domain model based on the capabilities of your persistence framework

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 21 download and individually named according to the names throughout the chapter.

How do you create, persist, and retrieve domain objects while maintaining a domain model that is not distracted by technical concerns? For domain objects that need to live beyond in- memory use and be retrieved later, a mapping to a persistence store is required. In order to avoid blurring the lines of responsibility between domain logic and infrastructure code, repositories can be employed. Repositories ensure that persistence ignorance is retained by storing domain aggregates behind a collection façade disguising the true underlying infrastructural mechanism. Repositories ensure technical complexities are kept out of the domain model.

Repositories

A repository is used to manage aggregate persistence and retrieval while ensuring that there is a separation between the domain model and the data model. It mediates between these two models by using a collection façade that hides the complexities of the underlying storage platform and any persistence framework. The repository provides similar functionality to a .NET collection for storing and removing aggregates, but it can also include more explicit querying functionality and offer summary information on the aggregate collection.

Repositories differ from traditional data access strategies in three ways:

They restrict access to domain objects by only allowing the retrieval and persistence of aggregate roots, ensuring all changes and invariants are handled by aggregates.
They keep up the persistence-ignorant façade by hiding the underlying technology used to persist and retrieve aggregates.
Most importantly, they define a boundary between the domain model and the data model.

So what does a repository look like? Listing 21-1 shows an interface for a repository that manages the persistence and retrieval of customer aggregates. The interface is kept within the domain model namespace because it is part of the domain model, with the implementation residing in the technical infrastructure namespace.

LISTING 21-1: The Interface of a Customer Repository


namespace DomainModel
{
  public interface ICustomerRepository
  {
    Customer FindBy(Guid id);
    void Add(Customer customer);
    void Remove(Customer customer);
  }
}

A typical client of a repository is the application service layer. A repository defines all the data-access methods that an application service requires to carry out a business task. The implementation comes under the infrastructure namespace and is usually backed by a persistence framework to do the heavy lifting. Listing 21-2 shows an implementation of the ICustomerRepository using the NHibernate framework.

LISTING 21-2: An Implementation of the ICustomerRepository


namespace Infrastructure.Persistence
{
    public class CustomerRepository : ICustomerRepository
    {
        private ISession _session;
        public CustomerRepository (ISession session)
        {
            _session = session;
        }
        public IEnumerable<Customer> FindBy(Guid id)
        {
            return _session.Load<Order>(id);
        }
      
        public void Add(Customer customer)
        {
            _session.Save(customer);
        }
       
        public void Remove(Customer customer)
        {
            _session.Delete(customer);
        }
    }
}

The implementation of the repository in this case simply delegates to NHibernate’s ISession interface, which acts as a gateway to the data model. The actual mapping of domain objects to the data model is handled via XML, fluent code, or attribute mapping. Because NHibernate provides POCO persistence (persistence without requiring the domain model objects to inherit or implement any classes), it can map the domain model directly to the data model. Don’t worry if you have no experience with NHibernate or Object Relational Mappers (ORMs); some implementation exercises at the end of this chapter explain how to use RavenDB, Entity Framework, and NHibernate to implement a repository.

The salient point to take away is that repositories hide technical complexity from your domain model, enabling domain objects to focus solely on business concepts and logic.

A Misunderstood Pattern

There is much misunderstanding and confusion around the repository pattern, with many regarding it as unnecessary ceremony and needless abstraction. When it’s not used in conjunction with a rich domain model, the repository pattern is overly complex and can be avoided for a simpler data access object or better by using a persistence framework directly. However, when modeling a solution for a complex domain, the repository is an extension of the model. It reveals the intent behind aggregate retrieval and can be written in a manner that is meaningful to the domain rather than a technical framework.

Is the Repository an Antipattern?

Many developers have negatively blogged that a repository is an antipattern because it hides the capabilities of an underlying persistence framework. This is actually the point of the repository. Instead of offering an open interface into the data model that supports any query or modification, the repository makes retrieval explicit by using named query methods and limiting access to the aggregate level. By making retrieval explicit, it becomes easy to tune queries, and more importantly express the intent of the query in terms a domain expert can understand rather than in SQL. Besides queries, the repository exposes meaningful persistence methods instead of blindly allowing all the create, read, update, and delete (CRUD) methods, regardless of how appropriate each may be.

The point of the repository pattern is not to make it easier to test your code or to make it easy to swap out underlying persistence storage options. It’s to keep your domain model and technical persistence framework separate so your model can evolve without being affected by the underlying technology. Without a repository layer, your persistence infrastructure will likely leak into your domain model and weaken its integrity and ultimately usefulness.

The backlash against the repository pattern seems to stem from a lack of understanding about where and why it should be used. It is a pattern that is useful in certain circumstances but not all. Just like a domain model pattern or any design pattern, blindly applying it to all problems results in more complexity, not less.

The Difference between a Domain Model and a Persistence Model

If your persistence store is a relational database and you are using an ORM—which is designed to remove the need to manually map objects to rows and properties to columns, and write raw SQL—you might be wondering why to bother implementing the repository pattern because you already have a framework that abstracts away the persistence technology. The issue, however, is that an ORM only abstracts the relational data model. It merely represents the data model in an object-oriented manner, enabling you to manipulate data easily in code.

The persistence model that your ORM maps to is different from your domain model, as shown in Figure 21.1. The persistence model is the one within your relational database; it’s made up of tables and columns, not entities and value objects. For some domain models, the data model may appear similar, or even the same, but conceptually they are very different. Your domain model is an abstraction of your problem domain, rich in behavior and language. The data model is simply a storage structure to contain the state of your domain model at a given time. ORMs map to the data model and make using it easier. They have little to do with domain models. The role of the repository is to keep the two models separate and not to let them blur into one. An ORM is not a repository, but a repository can use it to persist the state of domain objects.

images — **FIGURE 21.1** An ORM maps between the domain and persistence model.

If your domain model is similar to your data model, a sophisticated ORM like NHibernate may be able to map your domain objects directly to the datastore. However, if not, you may be best served having a completely separate data model instead of compromising your domain model. This chapter examines some of the options to achieve this a little later. For document stores, this problem doesn’t exist, and the domain model can be serialized without compromise.

The benefit to separating the data model from the domain model is that it allows you to evolve the domain model without having to constantly think of the data storage and how it will be persisted. Of course, it will ultimately need to be persisted, and you may need to take a pragmatic view and make compromises, but these compromises should be made only when absolutely required, and after the modeling effort is complete rather than up front with the creation of a model.

The Generic Repository

Developers love to reuse code. They generalize a concept to create a common class that can be used for all variations, even though separate explicit solutions would convey the intent of each concept far better. Often you see a form of generic repository contract defined within the domain model. Listing 21-3 shows such an interface with all the operations you would need, including an open-to- extension query method.

LISTING 21-3: A Generic Repository Interface


namespace DomainModel
{
  public interface IRepository<TAggregate, TId>
  {
    IEnumerable<TAggregate> FindAllMatching(Expression<Func<T, bool>> query);
    IEnumerable<TAggregate> FindAllMatching(string query);
    TAggregate FindBy(TId id);
    void Add(TAggregate aggregate);
    void Remove(TAggregate aggregate);
  }
}

A repository contract defined in the domain layer would inherit this interface and would resemble Listing 21-4.

LISTING 21-4: Inheriting from the Generic Repository Interface


namespace DomainModel
{
  public interface ICustomerRepository : IRepository<Customer, Guid>
  {
  }
}

The problem with a contract like this is that it assumes that all your aggregates support the same behavior and have the same needs. Some aggregates may be read only, and some may not support the remove method. When an aggregate does not support a concept, you will often find the repository implementation throwing an exception, as in Listing 21-5.

LISTING 21-5: A Concrete Implementation of the Customer Repository


namespace Infrastructure.Persistence
{
  public class CustomerRepository : ICustomerRepository
  {
     // ....
 
     public void Remove(Customer aggregate)
     {
       throw new NotImplementedException(
                      "A customer cannot be removed from the collection.");
     }
  }
}

Another problem with the interface is the leaky abstraction of the FindAllMatching methods. By providing a method open to extension, you are making it impossible to control queries and optimize fetching strategies. This support of ad hoc queries can quickly lead to severe performance problems in relational databases.

Trying to apply a generalizing strategy to all repositories is a bad idea. It says nothing about the intent behind the retrieval of aggregates. Like all problems, it is better to be explicit. Define your repositories based on their individual needs, and be explicit when naming query methods, as shown in Listing 21-6.

LISTING 21-6: A Specific Customer Repository Interface


namespace DomainModel
{
  public interface ICustomerRepository
  {
    Customer FindBy(Guid id);
    IEnumerable<Customer> FindAllThatAreDeactivated();
    void Add(Customer customer);
  }
}

When it comes to implementation, there is a place for the generic repository. Behind the concrete implementation, a generic repository can be used to avoid code duplication. As shown in Listing 21-7, this couples an explicit contract with the benefit of code reuse.

LISTING 21-7: The Customer Repository Uses Composition and Does Not Inherit from the Generic Repository


namespace Infrastructure.Persistence
{
  public class CustomerRepository : ICustomerRepository
  {
    private IRepository<Customer, Guid> _customersRepository;

    public Customers(IRepository<Customer, Guid> customersRepository)
    {
        _customersRepository = customersRepository;
    }
 
    // ....
 
    public IEnumerable<Customer> FindAllThatAreDeactivated()
    {
           _customersRepository.FindAllMatching(new
                               CustomerDeactivatedSpecification());
    }

    public void Add(Customer customer)
    {
        _customersRepository.Add(customer);
    }
  }
}

If you are using a persistence framework, there is no need to abstract it; you can use this directly within the concrete implementation of a repository. An example using the RavenDB framework is shown in Listing 21-8.

LISTING 21-8: The Customer Repository Does Not Abstract RavenDB


namespace Infrastructure.Persistence
{
    public class CustomerRepository : ICustomerRepository
    {
       private IDocumentSession _documentSession;
      
       public Customers(IDocumentSession documentSession)
       {
           _documentSession = documentSession;
       }
      
       // ....
      
       public IEnumerable<Customer> FindAllThatAreDeactivated()
      {
         return _documentSession.Query<Customer>()
                            .Where(x => x.Deactivated == true)
                            .ToList();

      }
      
       public void Add(Customer customer)
       {
           _documentSession.Store(customer);
       }
    }
}

Here you don’t abstract away from the underlying framework because there is no value in doing so. Remember that you are only keeping technical concerns out of the domain model. All other parts of the application need not abstract and hide the implementation details, because this misdirection only proves to confuse readers of the code.

Aggregate Persistence Strategies

Your design strategy, the shape of your aggregates, and whether you are working in a greenfield or a brownfield environment will affect the options for the way you persist your domain objects. The thing that should be at the front of your mind, however, is that you should create your domain objects without thinking about persistence requirements; that is the job of the repository. Your domain objects should be free from any infrastructural code and be as POCO (Plain Old C# Objects) as possible. Compromises should be made only as a last resort.

Using a Persistence Framework That Can Map the Domain Model to the Data Model without Compromise

If you are mapping to a relational database in a greenfield environment and you are using an ORM that supports persistent ignorant domain objects, you will be able to map your domain model directly to the data model, as shown in Figure 21.2.

An ORM usually uses reflection to persist your domain objects and supports the persistence of a fully encapsulated domain model with private getters and setters. Some ORMs require small additions to your domain objects, such as a parameterless constructor in the case of NHibernate, but this is a small price to pay for a seamless map from the domain to the data model.

If you are using a document store where the framework can serialize your aggregate, as shown in Figure 21.3, you will be able to map the aggregate directly without needing an additional mapping to a data model.

A framework that allows your domain model to be free of infrastructural concerns can enable you to evolve your model without compromise and can have a big impact on how you approach modeling.

Using a Persistence Framework That Cannot Map the Domain Model Directly without Compromise

If you are using a persistence framework that does not allow your domain model to be persistence ignorant, you need to take a different approach to the way you persist and retrieve your domain objects so they remain free of infrastructural concerns. There are a number of ways that you can achieve this, but all affect the domain model and the shape of your aggregates. This is, of course, the compromise you need to make your application work.

Public Getters and Setters

A simple method to enable the persistence of domain objects is to ensure that all properties have public getters and setters. The problem is that this leaves your domain objects open to being left in an invalid state because clients can bypass your state-altering methods. You can avoid this through code reviews and governance. However, exposing your properties does make it easy to persist your domain model because your repository has easy access to the domain object’s state.

In Listing 21-9, you can see that the Basket domain object has public properties for both its collection of items and its delivery cost. If a client bypasses the Add method and instead directly adds an item to the collection, the delivery cost is not updated.

LISTING 21-9: Making All Properties Public on the Basket Class


namespace DomainModel
{
    public class Basket
    {
        public Money DeliveryCost { get; set;}
        public IList<Item> Items { get; set; }

        public void Add(Product product)
        {
            if (AlreadyContains(product))
                FindItemFor(product).IncreaseItemQuantityBy(1);
            else
                Items.Add(BasketItemFactory.CreateItemFor(product));

                DeliveryCosts = DeliveryOption.CalculateDeliveryCostsFor(Items);
        }
    }
}

On the plus side, however, a repository implementation can keep the data model separate from the domain model. Listing 21-10 shows an example of what this might look like.

LISTING 21-10: The Basket Repository Hides the Complexities of Mapping the Basket Object to the Data Store


namespace Infrastructure.Persistence
{
    public class BasketRepository : BasketRepository
    { 	
        // ....
       
        public Basket FindBy(Guid id)
        {
            Basket basket;
           
            var basketDataModel = FindDataModelBy(id);

if (basketDataModel != null)
            {
                basket = new Basket();
basket.DeliveryCost = basketDataModel.DeliveryOptionCost;

foreach(var item in basketDataModel.Items)
                {
            basket.Items.Add(ItemFactory.CreateFrom(item);
}
            }

return basket;
        }
    }
}

In Listing 21-10, you can see that the data model is retrieved and then mapped to a new instance of the basket domain object. This enables the domain model to be completely unaware of any persistence store, but this is at the cost of exposing the properties of your domain model.

Using the Memento Pattern

If you don’t want to expose your domain model’s properties and want them to be totally encapsulated, you can utilize the memento pattern. The Gang of Four pattern lets you restore an object to a previous state. The previous state in this instance can be stored in a database. The way in which it works is that an aggregate produces a snapshot of itself that can be persisted. The aggregate would know how to hydrate itself from the same snapshot. It’s important to understand that the snapshot is not the data model; it’s merely the state of the aggregates, which again is free from any persistence framework. The repository would still have to map the snapshot to the data model. Figure 21.4 shows a graphical representation of this pattern.

Listing 21-11 shows an implementation of the memento pattern on the Basket aggregate.

LISTING 21-11: An Implementation of the Memento Pattern


namespace DomainModel
{
    public class Basket
    {
        private Basket(BasketSnapshot snapshot)
        {
            Items = CreateBasketItemsFrom(snapshot.ItemsSnapshot);
            DeliveryCost = snapshot.DeliveryCost;
        }

        // ...

        private Money DeliveryCost { get; set; }
        private IList<Item> Items { get; set; }

        public IEnumerable<ItemView> ShowItems()
        {
            return Items.ConvertToItemView();
        }

        public void Add(Product product)
        {
            if (AlreadyContains(product))
                FindItemFor(product).IncreaseItemQuantityBy(1);
            else
                Items.Add(BasketItemFactory.CreateItemFor(product));

            DeliveryCosts = DeliveryOption.CalculateDeliveryCostsFor(Items);
        }

        public BasketSnapshot GetSnapshot()
        {
            var snapshot = new BasketSnapshot();

            snapshot.ItemsSnapshot = CreateItemSnapshotFrom(Items);
            snapshot.DeliveryCost = this.DeliveryCost;

            return snapshot;
        }

        public static void CreateBasketFrom(BasketSnapshot snapshot)
        {
            return new Basket(snapshot);
        }
    }
}

The repository implementation would look like Listing 21-12.

LISTING 21-12: The Basket Repository Implementation


namespace Infrastructure.Persistence
{
    public class BasketRepository : BasketRepository
    { 
        // ....
       
        public Basket FindBy(Guid id)
        {
            Basket basket;
       
            BasketDataModel
            basketDataModel = FindDataModelBy(id);

            if (basketDataModel != null)
            {
                var basketSnapshot = ConvertToBasketSnshot(basketDataModel);

                basket = Basket.CreateBasketFrom(basketSnapshot);
            }

            return basket;
        }
    }
}

Another option is to map the snapshot directly to your data model if you are using a persistence framework that allows this but may not allow mapping a full domain object.

Event Streams

Another way to persist your domain model is to use an event stream. Event streams are similar to the memento pattern, but instead of taking a snapshot in time of your aggregate, your repository persists all the events that have occurred to the aggregate in the form of domain events. Listen for events from the domain, and map them to a data model. Again, you need a factory method to reconstruct and replay these events to rebuild the aggregate. Figure 21.5 shows a graphical representation. Event streams are coved in Chapter 22

Be Pragmatic

In all the strategies of domain-model persistence, it pays to be pragmatic. A pure domain model should be persistence ignorant in that it should be immune to changes required by the needs of any underlying persistence framework. Purity is good in theory, but in practice it can be difficult to achieve, and sometimes you must choose a pragmatic approach.

If you have a corporate policy on datastores or frameworks, you may need to make compromises when it comes to physically persisting your domain objects. Ensure that you choose a strategy that befits the framework and data storage options available. Don’t fight your framework, and recognize that you may need to change your domain model based on performance and scalability. However don’t think about these things; start pure, then be pragamatic when you need to. Don’t let technical framework drive your design; think in aggregates and explicit retrieval of data rather than ad hoc querying.

A Repository Is an Explicit Contract

The contract of a repository is more than just a CRUD interface. It is an extension of the domain model and is written in terms that the domain expert understands. Your repository should be built from the needs of the application use cases rather than from a CRUD-like data access standpoint. The application layer is the client that pulls aggregates from the repository and delegates work to them. Your domain model houses the contracts but rarely uses them except for a specific use case represented in a domain service.

The repository is not an object. It is a procedural boundary and an explicit contract that requires just as much effort when naming methods upon it as the objects in your domain model do. Your repository contract should be specific and intention revealing and mean something to your domain experts.

Consider the repository interface in Listing 21-13. It enables the client to query for domain objects by any means. The contract is flexible and open to extension, but it tells you nothing of the needs or the intent of the retrieving strategies at play in the domain model to obtain collections of aggregates. To truly understand how these methods are used, a developer needs to trawl through all the code to understand the intent and need of queries, let alone how to optimize them. Because the contract is so wide and unspecific, it becomes useless as a boundary and as an interface.

LISTING 21-13: A Repository Interface with Query Methods That Are Open to Extension


namespace DomainModel
{
  public interface ICustomerRepository
  {
    Customer FindBy(Guid id);
    IEnumerable<Customer> FindAllThatMatch(Query query);
    IEnumerable<Customer> FindAllThatMatch(String hql);
    void Add(Customer customer);
  }
}

Take a look at a different style of repository contract in Listing 21-14. The contract is explicit and tells you a lot about how aggregates are used. Gone are the open-to-extension methods, replaced by two explicit querying methods named in a manner that reveals intent and that is aligned to the language of the domain experts. You are applying the Tell, Don’t Ask principle, making the repository do all the hard work by abstracting the query method. It is now clear how you can optimize these queries in the infrastructure implementation.

LISTING 21-14: A Repository Interface with Explicit Query Methods


namespace DomainModel
{
  public interface ICustomerRepository
  {
    Customer FindBy(Guid id);
    IEnumerable<Customer> FindAllThatAreDeactivated();
    IEnumerable<Customer> FindAllThatAreOverAllowedCredit();
    void Add(Customer customer);
  }
}

The repository is the contract between the domain model and the persistence store. It should be written only in terms of the domain and without a thought to the underlying persistence framework. Define intent and make it explicit; do not treat the repository contract like object-oriented (OO) code.

Transaction Management and Units of Work

Transaction management is chiefly the concern of the application service layer. However, because the repository and transaction management are tightly aligned, it’s pertinent to mention them here. (A more detailed examination of transaction management can be found in the following chapter.) A repository is only concerned with the management of a single collection of aggregate roots, whereas a business case could result in updates to multiple types of aggregates.

Transaction management is handled by a unit of work. The role of the unit-of-work pattern is to keep track of all changes to aggregates during a business task. Once all changes have taken place, the unit of work then coordinates the updating of the persistence store within a transaction. To ensure that data integrity is not compromised if an issue arises partway through committing changes to the datastore, all changes are rolled back to ensure that the data remains in a valid state.

In NHibernate, the unit of work pattern is implemented by the session object. In Listing 21-15, an application service is dependent on two repositories to coordinate the task of applying loyalty points. To manage the transaction, a unit of work in the form of NHibernate’s session object is required. No changes are persisted to the database until the transaction started by the unit of work is committed.

LISTING 21-15: The Unit-of-Work Pattern Implemented Using NHibernate


namespace ApplicationLayer
{
        public class LoyalPointsAccumulator
        {
            private ILoyaltyAccountRepository _loyaltyAccountsRepo;
            private IOrderRepository _ordersRepo;
            private LoyaltyPointsCalculator _pointsCalculator;
            private ISession _session;

            public LoyalPointsAccumulator(
                    ILoyaltyAccountRepository loyaltyAccountsRepo,
                    IOrderRepository ordersRepo,
                    LoyaltyPointsCalculator pointsCalculator,
                    ISession session)
        {
                _loyaltyAccountsRepo = loyaltyAccountsRepo;
                _ordersRepo = ordersRepo;
                _pointsCalculator = pointsCalculator;
                _session = session;
        }

        public void CalculatePointsFor(Guid orderId)
        {
            using(var transaction = _session.BeginTransaction())
            {
                var order = _ordersRepo.FindMatching(orderId)
                var account = _loyaltyAccountsRepo.FindMatching(order.CustomerId)

                var points = _pointsCalculator.calculateFor(order);

                account.Add(points, orderid);

                order.Earns(points);

                transaction.Commit();
            }
        }
        }
}

You don’t need to abstract the underlying persistence framework at the application service level because there is no value to it. Here you are being explicit and using the NHibernate framework directly. It is only at the domain model that you need to keep persistence ignorance. At the application service layer, you don’t abstract the framework because it orchestrates both infrastructure and domain logic.

To make things a little clearer, Figure 21.6 shows how the repositories interact with the session object (NHibernate’s implementation of the unit-of-work pattern).

To ensure changes are made within the same transaction, the repositories must use the session instance, which the application service layer is using. This is achieved via employment of a factory or inversion of control container to create the application service, which is discussed in detail in the next chapter. The repository instance gets the session injected via its constructor, as shown in Listing 21-16.

LISTING 21-16: NHibernate Session Object Injected via the Constructor of the Repository


namespace Infrastructure.Persistence
{
    public class OrderRepository : IOrderRepository
    {
        private ISession _session;

        public OrderRepository(ISession session)
        {
            _session = session;
        }

        public void Add(Order order)
        {
            _session.Save(order);
        }
        
        public Order FindBy(Guid id)
        {
            return _session.Load<Order>(id);
        }
    }
}

Alternatively, you can use setter-based injection to ensure the repositories have access to the same session instance as the application service. This makes it even more explicit as to what is going on. Listing 21-17 shows how the application service would be updated to leverage setter-based injection on the repository.

LISTING 21-17: NHibernate Session Object Injected via the Repository’s Public Properties


namespace ApplicationLayer
{
       public class LoyalPointsAccumulator
       {
          // ....

         public void CalculatePointsFor(Guid orderId)
         {
           using(var transaction = _session.BeginTransaction())
           {
             _ordersRepo.EnlistIn(_session);
             _loyaltyAccountsRepo.EnlistIn(_session);

             var order = _ordersRepo.FindMatching(orderId)
             var account = loyaltyAccountsRepo.FindMatching(order.CustomerId)

             var points = _pointsCalculator.calculateFor(order);
             account.Add(points, orderid);
             order.Earns(points);

             transaction.Commit();
           }
         }
       }
}

Because the unit-of-work pattern has nothing to do with the domain and is purely a technical concern, it doesn’t make sense to include the EnlistIn method directly on the repository interface contract. You can instead use a separate interface for this to hide the enlist method and ensure you check for the existence of a session in the repository before carrying out any work (see Listing 21-18).

LISTING 21-18: Using Interface Segregation to Separate the Unit of Work and Repository Responsibilities


namespace Infrastructure.Persistence
{
    public interface IEnlistInAUnitOfWork
    {
        void EnlistIn(ISession session);
    }
}

namespace Infrastructure.Persistence
{
    public class OrderRepository : IOrderRepository, IEnlistInAUnitOfWork
    {
        private ISession _session;

        public void EnlistIn(ISession session)
        {
            _session = session;
        }
        
        public void Add(Order order)
        {
            _session.Save(order);
        }
        
        public Order FindBy(Guid id)
        {
            return _session.Load<Order>(id);
        }
    }
}

To Save or Not To Save

A repository should represent a collection of aggregates and behave just like a .NET collection, completely hiding the underlying persistence mechanism. A .NET collection holds references to objects, so any changes made to an object doesn’t require them to be explicitly updated within the collection. This means that you won’t find a save or update method on a collection; ideally, your repository would behave in the same manner. However, mimicking a collection-like façade is largely down to the capabilities of your persistence framework of choice. A persistence framework that does not support change tracking needs to expose a save method, and the application service that coordinates domain activity needs to ensure that it explicitly persists retrieved aggregates after changes are made to them. If you are choosing not to leverage some kind of persistence framework, you need to do a lot of work. It’s best to take a look at some of the options that can help you take the chore out of manual persistence.

Persistence Frameworks That Track Domain Object Changes

ORM frameworks such as NHibernate can track changes in objects that are retrieved by them. Because changes are tracked implicitly, the client of the repository, which is generally the application service, doesn’t need to explicitly save these objects. This means there is no requirement for a Save method on the repository contract because changes made are pushed to the persistence store when the unit of work is marked as complete. Consider Listing 21-19, showing both the repository contract and a sample application service. It uses an abstraction on the unit-of-work pattern, which can be implemented by a persistence framework or manually.

LISTING 21-19: NHibernate’s Repository Implementation Needs No Save Method


namespace DomainModel
{
  public interface ICustomerRepository
  {
    Customer FindBy(Guid id);
    IEnumerable<Customer> FindAllThatAreDeactivated();
    IEnumerable<Customer> FindAllThatAreOverAllowedCredit();
    void Add(Customer customer);	
  }
}

namespace ApplicationLayer
{
    public class LoyalPointsAccumulator
    {
        // ....

      public void CalculatePointsFor(Guid orderId)
      {
          var order = _ordersRepo.FindMatching(orderId)
          var account = _loyaltyAccountsRepo.FindMatching(order.CustomerId)

          var points = _pointsCalculator.calculateFor(order);

          account.Add(points, orderid);
 
          order.Earns(points);

          uow.Commit();
      }
    }
}

To track changes to domain objects, a persistence framework either takes a snapshot of the retrieved aggregates at read time and compares when persisting the unit of work to determine what to persist, or it returns a proxy of the aggregate and tracks changes as they happen. Once the call to the commit on the unit of work is made, the framework determines if any change has occurred and then generates the SQL required to persist that change in the data model.

Having to Explicitly Save Changes to Aggregates

If you are using a framework to map a data model that does not support change tracking, such as a micro ORM, or you are using raw ADO.NET, you need to support a save method on the repository contract and ensure that the application service calls with the changed domain object. Listing 21-20 shows a repository interface with the Save method and how the application service would use it. You can still call the unit of work to ensure that all changes occur within a transaction.

LISTING 21-20: A Repository Implementation with a Save Method


namespace DomainModel
{
  public interface ICustomerRepository
  {
    Customer FindBy(Guid id);
    IEnumerable<Customer> FindAllThatAreDeactivated();
    IEnumerable<Customer> FindAllThatAreOverAllowedCredit();
    void Add(Customer customer);
    void Save(Customer customer);
  }
}

namespace ApplicationLayer
{
    public class LoyalPointsAccumulator
    {
        // ....
    public void CalculatePointsFor(Guid orderId)
    {
        var order = _ordersRepo.FindMatching(orderId)
        var account = _loyaltyAccountsRepo.FindMatching(order.CustomerId)

        var points = _pointsCalculator.calculateFor(order);

        account.Add(points, orderid);

        order.Earns(points);

        _ordersRepo.Save(order);
        _loyaltyAccountsRepo.Save(account);

        uow.Commit();
    }
}
}

The Repository as an Anticorruption Layer

When you’re working in a brownfield environment with an existing persistence store, a repository can help keep the domain model pure by acting as an anticorruption layer, enabling you to create a model without its shape being affected by any underlying infrastructure complexities.

As you have read, a data model and a domain model can be very different. A data model may be spread over several tables or even databases. Also, multiple forms of persistence store can be used, such as flat files, web services, and relational or NoSQL stores. Whatever persistence store you find yourself using, it should not shape the domain model. Repositories map to aggregates, not tables; for example, more than one entity can occupy a single table, as was covered in Chapter 16, where it was shown how to use explicit implementations for different states. Repositories can also store a model over more than a single data store, as shown in Figure 21.7.

Other Responsibilities of a Repository

Besides the persistence and retrieval of aggregates, the repository pattern can expose other facts about its collection of domain objects. For instance, a repository can expose the number of aggregates in its collection, as shown in Listing 21-21.

LISTING 21-21: A Customer Repository with Collection Methods


namespace DomainModel
{
  public interface ICustomerRepository
  {
    Customer FindBy(Guid id);
    IEnumerable<Customer> FindAllThatAreDeactivated();
    IEnumerable<Customer> FindAllThatAreOverAllowedCredit();
    void Add(Customer customer);
    int Count();
  }
}

Entity ID Generation

If your database or another infrastructural service controls the seeding of IDs, you can abstract this behind the repository and expose it to the application service. It can provide identity explicitly via a method on the interface, as shown in listing 21-22.

LISTING 21-22: Abstracting the Seeding of IDs


namespace DomainModel
{
  public interface ICustomerRepository
  {
    Customer FindBy(Guid id);
    IEnumerable<Customer> FindAllThatAreDeactivated();
    IEnumerable<Customer> FindAllThatAreOverAllowedCredit();
    void Add(Customer customer);
    Guid GenerateId()
  }
}

namespace ApplicationLayer
{
    public class CustomerRegistration
    {
        private ILoyaltyAccountRepository _loyaltyAccountRepo;
        private ICustomerRepository _customerRepo;
        private ISession _session

        public CustomerRegistration(
                                  ILoyaltyAccountRepository loyaltyAccountRepo,
                                  ICustomerRepository customerRepo,
                                  ISession session)
        {
            _loyaltyAccountRepo = loyaltyAccountRepo;
            _customerRepo = customerRepo;
            _session = session;
        }

        public void Register(CustomerDetail details)
        {
            using(var transaction = _session.BeginTransaction())
            {
                var newCustomerId = _customerRepo.GenerateId();
                var customer = CustomerRegistration.CreateFrom(
                                                details, newCustomerId);

                _customerRepo.Add(customer);

                var loyaltyAccount = new LoyaltyAccount(newCustomerId);

                _loyaltyAccountRepo.Add(loyaltyAccount);

                transaction.Commit();
            }
        }
    }
}

A repository can also assign an ID during persistence. Usually this is accomplished by having the datastore as the seed for an entity’s ID. Listing 21-23 shows part of the XML mapping document for NHibernate. The nested generator tag class attribute defines what generates the ID of the entity. In this case, it is native, and the underlying database automatically generates IDs for the entity via the database identity-seed data type. Later you will see other options for generating the identifier of the entity. The unsaved value attribute is used by NHibernate to compare with the business entity’s identifier to help determine if an object has been persisted or is transient (unsaved).

LISTING 21-23: Part of the XML Mapping Document for NHibernate


       <?xml version="1.0" encoding="utf-8" ?>
       <hibernate-mapping
          namespace="DomainModel" assembly="DomainModel">

       <class name="Order" table="Orders" lazy="false" >

       <id name="Id" column="OrderId" type="int" unsaved-value='0'>
          <generator class="native" />
       </id>

      // ....
    
  </class>
</hibernate-mapping>

Don’t worry if you are not familiar with NHibernate because you will be working through some exercises at the end of this chapter to show you how to implement these patterns in practice.

Collection Summaries

Besides counting the number of aggregates you have in a collection, you may want some other summary information on what the collection contains without having to pull back each aggregate and summarize manually. In Listing 21-24, the summary value object can give counts on specific types of customers. For intensive queries and calculations that are best run closer to the raw data, a summary view can be extremely powerful.

LISTING 21-24: A Repository with Summary Methods


namespace DomainModel
{
  public interface ICustomerRepository
  {
    Customer FindBy(Guid id);
    IEnumerable<Customer> FindAllThatAreDeactivated();
    IEnumerable<Customer> FindAllThatAreOverAllowedCredit();
    void Add(Customer customer);
    Summary Summary();
  }
}

namespace DomainModel
{
    public class Summary
    {
        public int CustomersCount { get; set; }
        public int DeactivatedCustomers { get; set; }
        public int CustomersOverAllowedCredit { get; set; }
    }
}

Concurrency

When multiple users are concurrently changing the state of a domain object, it is important that users are working against the latest version of an aggregate and that their changes don’t overwrite other changes that they are not aware of. There are two forms of concurrency control: optimistic and pessimistic. The optimistic concurrency option assumes that there are no issues with multiple users making changes simultaneously to the state of business objects, also known as last change wins. For some systems, this is perfectly reasonable behavior; however, when the state of your business objects needs to be consistent with the state when retrieved from the database, pessimistic concurrency is required.

Pessimistic concurrency can come in many flavors, from locking the data table when a record is retrieved to keeping a copy of the original contents of a business object and comparing that to the version in the datastore before an update is made to ensure there have been no changes to a record during a transaction. Many persistence frameworks use a version number to check whether a business entity has been amended since being retrieved from the database. Upon an update, the version number of the business entity is compared to the version number residing in the database before committing a change. This ensures that the business entity has not been modified since being retrieved.

As an example, NHibernate supports optimistic concurrency in several ways. One method that it employs is to use a version tag in the XML mapping file, as shown in Listing 21-25.

LISTING 21-25: An Entity with a Version Field


namespace DomainModel
{
  public class Product
  {
    private int _version;

    // ...
  }
}

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
    namespace="DomainModel" assembly="DomainModel">

  <class name="Product" table="Products" lazy="false" >

    <id name="Id" column="Id" type="int" unsaved-value="0">
      <generator class="native" />
    </id>

    // ....
    
       <version name="Version"  column="Version"/>
  </class>
</hibernate-mapping>

The Version property is set when the Product entity is retrieved from the datastore. If you feel uncomfortable with the Version property being on the Product entity because in the domain that you are modeling, a version isn’t an attribute of a product, you could use an Entity Layer Supertype class, as shown in Listing 21-26 (see also Chapter 16) or return a proxy version of the Product entity and include the version ID within.

LISTING 21-26: A Verison Property Added to an Entity Base Class


namespace Infrastructure
{
    public abstract class Entity
    {
        public int version {get; private set; };
    }
}

namespace DomainModel
{
    public class Product : Entity
   {
       // ...
    }
}

In Listing 21-27 from an application service class, you can see that when a Product entity is being saved to the database, the version of the changed entity is included in the where clause. NHibernate compares the values and throws a StaleObjectStateException because the Person object has been modified since you made your second change. The program should then alert the user that the Product entity has changed or been deleted since the original retrieval and the update have failed.

LISTING 21-27: Application Service Handling Concurrency Exceptions


namespace ApplicationLayer
{
    public class Pricing
    {
        private IProductRepository _productRepository;
        private ISession _session;

        public class Pricing(IProductRepository productRepo, ISession session)
        {
            _productRepository = productRepo;
            _session = session;
        }

        public void SetPrice(
                    UpdatedProductPriceInformation updatedProductInformation)
        {
            try
            {
                using(var transaction = _session.BeginTransaction())
                {
                    var product = _productRepo
                                 .FindBy(updatedProductInformation.ProductId);
                
                    product.SetPriceTo(updatedProductInformation.NewPrice);
                    
                    transaction.Commit();
                }
            }
            catch (StaleObjectStateException ex)
            {
                // The product has changed in the time between retrieving it
                // and committing the transaction
            }
        }
    }
}

In Listing 21-27, an exception is thrown if the product was modified in the small amount of time between retrieving it from the persistence store to commit the changes on it. What is more likely is that a product changes while the user is viewing it on her desktop/browser. In this situation, the product can be updated while the user is reviewing the data, and the user can then overwrite changes unbeknownst to her. To prevent this from happening, the version flag should be sent to the UI with the view model, and the same version should be sent back with the UpdatedProductPriceInformation command. The updated code in Listing 21-28 checks to see if the version that the user was using is the same as the one retrieved from the repository. If it’s not, an exception is thrown, and the user can request the fresh updated data and review it again before submitting a price update.

LISTING 21-28: Checking the Version Property of an Entitiy Based on the User Interface


namespace ApplicationLayer
{
    public class Pricing
    {
        private IProductRepository _productRepo;
        private ISession _session;

        public class Pricing(IProductRepository productRepo, ISession session)
        {
            _productRepo = productRepo;
            _session = session;
        }

        public void SetPrice(
                      UpdatedProductPriceInformation updatedProductInformation)
        {
            try
            {
                using(var transaction = _session.BeginTransaction())
                {
                    var product = _productRepo
                                 .FindBy(updatedProductInformation.ProductId);

                    if (updatedProductInformation.Version != product.Version)
                        throw new ProductHasBeenUpdatedSinceViewingException();

                    product.SetPriceTo(updatedProductInformation.NewPrice);

                    transaction.Commit();
                }
            }
            catch (StaleObjectStateException ex)
            {
                Throw New StaleDataUpdateReportBeforeSendingCommmand();
            }
        }
    }
}

Audit Trails

If your data model requires metadata that does not make sense in your domain, you can utilize your repository to meet the requirements. Often changes to objects need to be marked with a last change date, which has no meaning to the domain. You can apply this metadata via the repository implementation.

Audit trails and logging can also be supplied via the repository. If you are deleting an aggregate, the repository can log the event for auditing and perhaps take a snapshot of the aggregate or a summary of it.

Repository Antipatterns

As with any pattern there are a number of recommended practices that should be avoided. These are known as antipatterns.

Antipatterns: Don’t Support Ad Hoc Queries

A repository is an explicit contract between the domain model and the persistence mechanism. By exposing a generic catch-all method for querying in an ad hoc manner, you are weakening this layer of abstraction. Consider the contract in Listing 21-29.

LISTING 21-29: Exposing Generic FindBy Methods Instead of Being Explicit


public interface ICustomerRepository
{
   void Add(Customer customer);
   Customer FindBy(Guid Id);
   IEnumerable<Customer> FindBy(CustomerQuery query);
}

The FindBy method takes some form of customer query, perhaps in the form of a specification. The challenge here is that the client can write any type of query, meaning all fetch paths need to be optimized. A method like this weakens the repository’s contract and completely removes the intent and meaning of querying the repository. The repository should not be open to extension; it is a boundary and procedural in nature. Instead, favor named methods so that you can write specific code that can be performance tuned and tailored to the underling persistence framework. New methods that are added can then be tuned, and the most appropriate fetching strategy can be created.

Exposing IQueryable on a repository is another flavor of supporting ad hoc query methods. The IQueryable interface is an extremely flexible pattern for data access; however, it can enable your data model to leak into your domain model. There is nothing wrong with using the IQueryable interface behind the boundary of your repository or directly accessing the data model for reporting needs, as shown in Listing 21-30.

LISTING 21-30: The Customer Repository Interface Contract


public interface ICustomerRepository
{
   void Add(Customer customer);
   Customer FindBy(Guid Id);
   IQueryable<Customer> Customers();
}

Antipatterns: Lazy Loading Is Design Smell

Aggregates should be built around invariants and contain all the properties necessary to enforce those invariants. Therefore, when loading an aggregate, you need to load all of it or none of it. If you have a relational database and are using an ORM for your data model, you may be able to lazy load some domain object properties. This enables you to defer loading parts of an aggregate you don’t need. However, the problem with this is that if you can get away with only partially loading an aggregate, you probably have your aggregate boundaries wrong. Also, if data-fetching patterns are affecting your aggregates, you may have built aggregates around views and not business rules.

Antipatterns: Don’t Use Repositories for Reporting Needs

The needs of your user-interface screens and the needs of business logic are very different. There will often be a mismatch between information required for a screen and the data contained within a single aggregate root. If only one or two properties are required for display purposes, an entire aggregate needs to be hydrated. Worse still, your domain objects may need extra information to support views that may make little sense to the domain objects they are attached to.

Further still, if you’re creating a view model for a screen that spans multiple aggregate roots, you need to pull them all back and pick out the information you require.

Running reports using a transaction model can be slow and compromise the integrity of your model because of the additional properties for UI screens. It is better to use a framework to directly query a read store; this could be the same datastore you use for the transactional work, or it could be a denormalized store.

Don’t abstract the persistence framework when querying your data model for reporting purposes. You’ll read more about this in the next chapter.

Repository Implementations

In this section, you will work through some repository implementations based on popular .NET persistence frameworks, namely:

NHibernate
RavenDB
Entity Framework
Dapper Micro ORM

For the examples, you will use a small domain model based on the bidding logic of eBay. Figure 21.8 shows the domain model you will be using. You will not be following a test-first development methodology, because this is an exercise to show you an implementation of a repository rather than how to drive the design of your domain model. With this in mind, you will build up the solutions in a manner where you can follow along and create them yourself.

The model represents the logic that handles eBay’s automatic bidding mechanism:

When a bidder makes a bid, he enters the maximum amount that he is willing to pay for the item. However, his actual bid is the minimum amount required to beat the previous bid or starting price.
When a second bidder places a bid, an automatic bidder bids on behalf of the previous bidder up to his maximum amount or enough to beat the second bidder.
If the second bidder exceeds the previous bidder’s maximum bid, the previous bidder is notified that he has been outbid.
If the second bidder matches the previous bidder’s maximum bid, the previous bidder is still the winner of the auction because he was first to bid.

Each of the persistence frameworks that you will use will have a small impact on your domain model. The examples will demonstrate that no matter what persistence framework you are using, you can still support a domain model that is persistent ignorant.

Persistence Framework Can Map Domain Model to Data Model without Compromise

The first two examples of repository implementation use NHibernate and RavenDB. Both of these frameworks allow direct mapping of a domain model to a data model with little or no compromise.

NHibernate Example

NHibernate is a port of the popular open source Hibernate framework for Java. It’s a framework that has been around for years, and it’s a proven and robust piece of software. NHibernate is an ORM. One of the best features of NHibernate is the support for persistence ignorance; this means that your business objects don’t have to inherit from base classes or implement framework interfaces. NHibernate uses an instance of an ISession, which is an implementation of the unit of work pattern. ISession is also the object you use to query your database with. It acts as your persistence manager and gateway into the database, allowing you to query against it, as well as saving, deleting, and adding entities. There are a number of ways to map business objects to database tables in NHibernate. One of the most popular is via an XML configuration file, but attributes and a fluent code mapping option are also available. This example uses the older XML mapping style.

The domain model in this example has no public properties and is totally encapsulated. You use NHibernate’s ability to persist encapsulated models.

Solution Setup

Create a new blank Visual Studio solution named DDDPPP.Chap21.NHibernateExample and add to this a class library named DDDPPP.Chap21.NHibernateExample.Application and a console application named DDDPPP.Chap21.NHibernateExample.Presentation. Within the Presentation project, add a reference to the application. Next, create the following folders in the DDDPPP.Chap21.NHibernateExample.Application project:

Application
Infrastructure
Model

You can delete Class1.cs that is automatically created because you won’t be needing it. Your solution should now match Figure 21.9.

Before you build out the application, you need to reference the NHibernate assemblies. Open the NuGet package manager and install NHibernate, as shown in Figure 21.10.

Creating the Model

The first thing you are going to do is to create the model. You will be utilizing domain events, so you need to create the infrastructure to support raising and handling events. You will use the framework that you built in Chapter 18, “Domain Events.” Add a new class to the Infrastructure folder of the Application class library project called DomainEvents with Listing 21-31. You can find details about how this class works in Chapter 18.

LISTING 21-31: The Domain Event’s Infrastructure Class


using System;
using System.Collections.Generic;

namespace DDDPPP.Chap21.NHibernateExample.Application.Infrastructure
{
      /// <summary>
      /// Domain Events class from
      ///  http://www.udidahan.com/2008/08/25/domain-events-take-2/
      /// </summary>
      public static class DomainEvents
      {
          [ThreadStatic]
          private static List<Delegate> _actions;
          private static List<Delegate> Actions
          {
              get
              {
                  if (_actions == null)
                  {
                      _actions = new List<Delegate>();
                  }
                  return _actions;
              }
          }
         
          public static IDisposable Register<T>(Action<T> callback)
          {
              Actions.Add(callback);

              return new DomainEventRegistrationRemover(() =>
                                            Actions.Remove(callback));
          }

          public static void Raise<T>(T eventArgs)
          {
              foreach (Delegate action in Actions)
              {
                  Action<T> typedAction = action as Action<T>;
                  if (typedAction != null)
                  {
                      typedAction(eventArgs);
                  }
              }
          }
       
          private sealed class DomainEventRegistrationRemover : IDisposable
          {
              private readonly Action _callOnDispose;

              public DomainEventRegistrationRemover(Action toCall)
              {
                  _callOnDispose = toCall;
              }

              public void Dispose()
              {
                  _callOnDispose();
              }
          }
      }
}

You will also be using the value object base class that was covered in Chapter 15, “Value Objects.” Create the ValueObject class, as defined in Listing 21-32, in the Infrastructure folder.

LISTING 21-32: The Value Object Base Class


using System.Collections.Generic;
using System.Linq;

namespace DDDPPP.Chap21.NHibernateExample.Application.Infrastructure
{
    public abstract class ValueObject<T> where T : ValueObject<T>
    {
        protected abstract IEnumerable<object>

        GetAttributesToIncludeInEqualityCheck();

        public override bool Equals(object other)
        {
            return Equals(other as T);
        }

        public bool Equals(T other)
        {
            if (other == null)
            {
                return false;
            }
            return GetAttributesToIncludeInEqualityCheck().SequenceEqual(
                            other.GetAttributesToIncludeInEqualityCheck());
        }

        public static bool operator ==(ValueObject<T> left,
                                                     ValueObject<T> right)
        {
            return Equals(left, right);
        }

        public static bool operator !=(ValueObject<T> left,
                                                     ValueObject<T> right)
        {
            return !(left == right);
        }

        public override int GetHashCode()
        {
            int hash = 17;
            foreach (var obj in this.GetAttributesToIncludeInEqualityCheck())
                hash = hash * 31 + (obj == null ? 0 : obj.GetHashCode());

            return hash;
        }
    }
}

The last piece of infrastructure is to create a base class for the entities within the model, as shown in Listing 21-33.

LISTING 21-33: The Entity Base Class


namespace DDDPPP.Chap21.NHibernateExample.Application.Infrastructure
{
    public abstract class Entity<TId>
    {
        public TId Id { get; protected set; }
    }
}

With the infrastructure sorted, you can build out the domain model. From within the Model folder of the DDDPPP.Chap21.NHibernateExample.Application project, create the following two folders that will contain the two aggregates that make up the domain model.

Auction
BidHistory

The first aggregate that you will build is the Auction aggregate. The Auction aggregate contains all the domain rules around placing bids. You need a value object to represent the money concept in the model. Using Listing 21-34, create a value object named Money in the Auction folder.

LISTING 21-34: The Money Value Object


using System;
using System.Collections.Generic;
using DDDPPP.Chap21.NHibernateExample.Application.Infrastructure;

namespace DDDPPP.Chap21.NHibernateExample.Application.Model.Auction
{
    public class Money : ValueObject<Money>, IComparable<Money>
    {
        protected decimal Value { get; set; }

        public Money() : this(0m)
        {
        }

        public Money(decimal value)
        {
            ThrowExceptionIfNotValid(value);

            Value = value;
        }

        private void ThrowExceptionIfNotValid(decimal value)
        {
            if (value % 0.01m != 0)
                throw new MoreThanTwoDecimalPlacesInMoneyValueException();

            if(value < 0)
                throw new MoneyCannotBeANegativeValueException();
        }

        public Money Add(Money money)
        {
            return new Money(Value + money.Value);
        }

        public bool IsGreaterThan(Money money)
        {
            return this.Value > money.Value;
        }

        public bool IsGreaterThanOrEqualTo(Money money)
        {
            return this.Value > money.Value || this.Equals(money);
        }

        public bool IsLessThanOrEqualTo(Money money)
        {
            return this.Value < money.Value || this.Equals(money);
        }

        public override string ToString()
        {
            return string.Format("{0}", Value);
        }

            public int CompareTo(Money other)
               {
                   return this.Value.CompareTo(other.Value);
               }

            protected override IEnumerable<object>
                                   GetAttributesToIncludeInEqualityCheck()
            {
                return new List<Object>() {Value};
            }
    }
}

As you read in Chapter 15, a value object is immutable; you cannot alter its state. This is why the add method returns a new Money object rather than changing the state of the object itself.

In the constructor, there is a small piece of logic that ensures you have a nonnegative money amount. If not, one of the following two exceptions in Listing 21-35 is thrown. Add these two classes to the Auctions folder.

LISTING 21-35: Domain Exceptions


namespace DDDPPP.Chap21.NHibernateExample.Application.Model.Auction
{
    public class MoneyCannotBeANegativeValueException : Exception
    {
    }
}

namespace DDDPPP.Chap21.NHibernateExample.Application.Model.Auction
{
    public class MoreThanTwoDecimalPlacesInMoneyValueException : Exception
    {
    }
}

The next concept that you have in your auction domain is that of an offer. An offer is how much a bidder is willing to pay for an item in the auction. The reason you have the concept of an offer is that only offers that exceed the bid increment are turned into bids. The Offer class is also a value object. Create the Offer class within the Auction folder with the code shown in Listing 21-36.

LISTING 21-36: The Office Value Object


using System;
using System.Collections.Generic;
using DDDPPP.Chap21.NHibernateExample.Application.Infrastructure;

namespace DDDPPP.Chap21.NHibernateExample.Application.Model.Auction
{
    public class Offer : ValueObject<Offer>
    {
        public Offer(Guid bidderId, Money maximumBid, DateTime timeOfOffer)
        {
            if (bidderId == Guid.Empty)
                throw new ArgumentNullException("BidderId cannot be null");

            if (maximumBid == null)
                throw new ArgumentNullException("MaximumBid cannot be null");

            if (timeOfOffer == DateTime.MinValue)
                throw new ArgumentNullException(
                                  "Time of Offer must have a value");

            Bidder = bidderId;
            MaximumBid = maximumBid;
            TimeOfOffer = timeOfOffer;
        }

        public Guid Bidder { get; private set; }
        public Money MaximumBid { get; private set; }
        public DateTime TimeOfOffer { get; private set; }

        protected override IEnumerable<object>
                                    GetAttributesToIncludeInEqualityCheck()
        {
            return new List<Object>()
            {
                Bidder, MaximumBid, TimeOfOffer
            };
        }
    }
}

The auction price represents the current price of the winning bid; the price has a method that calculates the bid increment. This is again a value object. Add the Price class to the Model folder with Listing 21-37. In the real eBay bidding system, there are far more bid increment levels. Here there are only three to keep the exercise simple.

LISTING 21-37: The Price Value Object


using System;
using System.Collections.Generic;
using DDDPPP.Chap21.NHibernateExample.Application.Infrastructure;

namespace DDDPPP.Chap21.NHibernateExample.Application.Model.Auction
{
    public class Price : ValueObject<Price>
    {
        public Price(Money amount)
        {
            if (amount == null)
                throw new ArgumentNullException("Amount cannot be null");

            Amount = amount;
        }

        public Money Amount { get; private set; }

        public Money BidIncrement()
        {
            if (Amount.IsGreaterThanOrEqualTo(new Money(0.01m)) &&
                             Amount.IsLessThanOrEqualTo(new Money(0.99m)))
                    return Amount.add(new Money(0.05m));

            if (Amount.IsGreaterThanOrEqualTo(new Money(1.00m)) &&
                             Amount.IsLessThanOrEqualTo(new Money(4.99m)))
                    return Amount.add(new Money(0.20m));
                
            if (Amount.IsGreaterThanOrEqualTo(new Money(5.00m)) &&
                             Amount.IsLessThanOrEqualTo(new Money(14.99m)))
                    return Amount.add(new Money(0.50m));

            return Amount.add(new Money(1.00m));
        }

        public bool CanBeExceededBy(Money offer)
        {
            return offer.IsGreaterThanOrEqualTo(BidIncrement());
        }

        protected override IEnumerable<object>
                                GetAttributesToIncludeInEqualityCheck()
        {
            return new List<Object>() {Amount};
        }
    }
}

The WinningBid, yet another value object, represents a bidder’s accepted offer. Create the WinningBid class within the Model folder with Listing 21-38.

LISTING 21-38: The Winning Bid Value Object


using System;
using System.Collections.Generic;
using DDDPPP.Chap21.NHibernateExample.Application.Infrastructure;

namespace DDDPPP.Chap21.NHibernateExample.Application.Model.Auction
{
    public class WinningBid : ValueObject<WinningBid>
         public WinningBid(Guid bidder, Money maximumBid,
                          Money bid, DateTime timeOfBid)
        {
            if (bidder == Guid.Empty)
                throw new ArgumentNullException("Bidder cannot be null");

            if (maximumBid == null)
                throw new ArgumentNullException("MaximumBid cannot be null");

            if (timeOfBid == DateTime.MinValue)
                throw new ArgumentNullException("TimeOfBid must have a value");

            Bidder = bidder;
            MaximumBid = maximumBid;
            TimeOfBid = timeOfBid;
            CurrentAuctionPrice = new Price(bid);
        }
        
        public Guid Bidder { get; private set; }
        public Money MaximumBid { get; private set; }
        public DateTime TimeOfBid { get; private set; }
        public Price CurrentAuctionPrice { get; private set; }

        public WinningBid RaiseMaximumBidTo(Money newAmount)
        {
            if (newAmount.IsGreaterThan(MaximumBid))
                return new WinningBid(Bidder, newAmount,
                                      CurrentAuctionPrice.Amount,
                                      DateTime.Now);
            else
                throw new ApplicationException(
            "Maximum bid increase must be larger than current maximum bid.");
        }

        public bool WasMadeBy(Guid bidder)
        {
            return Bidder.Equals(bidder);
        }

        public bool CanBeExceededBy(Money offer)
        {
            return CurrentAuctionPrice.CanBeExceededBy(offer);
        }

        public bool HasNotReachedMaximumBid()
        {
            return MaximumBid.IsGreaterThan(CurrentAuctionPrice.Amount);
        }

        protected override IEnumerable<object>
                         GetAttributesToIncludeInEqualityCheck()
        {
            return new List<Object>() { Bidder, MaximumBid,
                                        TimeOfBid, CurrentAuctionPrice };
        }
    }
}

The domain service AutomaticBidder bids on a member’s behalf up to his maximum bid if he is outbid. It bids only as much as needed to remain the highest bidder, up to the bidder’s maximum amount. Create the AutomaticBidder class in the Model folder with Listing 21-39.

LISTING 21-39: The Automatic Bidder Domain Service


using System.Collections.Generic;

namespace DDDPPP.Chap21.NHibernateExample.Application.Model.Auction
{
    public class AutomaticBidder
    {
        public IEnumerable<WinningBid> GenerateNextSequenceOfBidsAfter(
                                  Offer offer, WinningBid currentWinningBid)
        {
            var bids = new List<WinningBid>();

            if (currentWinningBid.MaximumBid
                          .IsGreaterThanOrEqualTo(offer.MaximumBid))
            {
                var bidFromOffer = new WinningBid(offer.Bidder,
                                                  offer.MaximumBid,
                                                  offer.MaximumBid,
                                                  offer.TimeOfOffer);
                bids.Add(bidFromOffer);

                bids.Add(CalculateNextBid(bidFromOffer,
                         new Offer(currentWinningBid.Bidder,
                                         currentWinningBid.MaximumBid,
                                         currentWinningBid.TimeOfBid)));
            }
            else
            {
                if (currentWinningBid.HasNotReachedMaximumBid())
                {
                    var currentBiddersLastBid =
                           new WinningBid(currentWinningBid.Bidder,
                                          currentWinningBid.MaximumBid,
                                          currentWinningBid.MaximumBid,
                                          currentWinningBid.TimeOfBid);
                    bids.Add(currentBiddersLastBid);

                    bids.Add(CalculateNextBid(currentBiddersLastBid, offer));
                }
                else
                    bids.Add(new WinningBid(offer.Bidder,
                     currentWinningBid.CurrentAuctionPrice.BidIncrement(),
                     offer.MaximumBid, offer.TimeOfOffer));
            }

            return bids;
        }

        private WinningBid CalculateNextBid(WinningBid winningbid, Offer offer)
        {
            WinningBid bid;

            if (winningbid.CanBeExceededBy(offer.MaximumBid))
                bid = new WinningBid(offer.Bidder, offer.MaximumBid,
                                 winningbid.CurrentAuctionPrice.BidIncrement(),
                                 offer.TimeOfOffer);
            else
                bid = new WinningBid(offer.Bidder, offer.MaximumBid,
                                     offer.MaximumBid, offer.TimeOfOffer);

            return bid;
        }
    }
}

BidPlaced is a domain event signifying that a bid was placed. Add the class to the Model folder using Listing 21-40.

LISTING 21-40: The Bid Place Value Object


using System;

namespace DDDPPP.Chap21.NHibernateExample.Application.Model.Auction
{
    public class BidPlaced
    {
        public BidPlaced(Guid auctionId, Guid bidderId,
                         Money amountBid, DateTime timeOfBid)
        {
            if (auctionId == Guid.Empty)
                throw new ArgumentNullException("Auction Id cannot be null");

            if (bidderId == Guid.Empty)
                throw new ArgumentNullException("Bidder Id cannot be null");

            if (amountBid == null)
                throw new ArgumentNullException("AmountBid cannot be null");

            if (timeOfBid == DateTime.MinValue)
                throw new ArgumentNullException("TimeOfBid must have a value");

            AuctionId = auctionId;
            Bidder = bidderId;
            AmountBid = amountBid;
            TimeOfMemberBid = timeOfBid;
        }

        public Guid AuctionId { get; private set; }
        public Guid Bidder { get; private set; }
        public Money AmountBid { get; private set; }
        public DateTime TimeOfMemberBid { get; private set; }
    }
}

The OutBid class is another domain event. It is raised if a bidder is outbid, as shown in Listing 21-41.

LISTING 21-41: The Outbid Value Object


using System;

namespace DDDPPP.Chap21.NHibernateExample.Application.Model.Auction
{
    public class OutBid
    {
        public OutBid(Guid auctionId, Guid bidderId)
        {
            if (auctionId == Guid.Empty)
                throw new ArgumentNullException("Auction Id cannot be null");

            if (bidderId == Guid.Empty)
                throw new ArgumentNullException("Bidder Id cannot be null");

            AuctionId = auctionId;
            Bidder = bidderId;
        }

        public Guid AuctionId { get; private set; }
        public Guid Bidder { get; private set; }
    }
}

The Auction shown in Listing 21-42 is an entity and the aggregate root. The Auction class has no public properties and only exposes a single method to enable bids to be placed. The results of bids placed are raised as domain events.

LISTING 21-42: The Auction Entity


using System;
using DDDPPP.Chap21.NHibernateExample.Application.Infrastructure;

namespace DDDPPP.Chap21.NHibernateExample.Application.Model.Auction
{
    public class Auction : Entity<Guid>
    {
        public Auction(Guid id, Money startingPrice, DateTime endsAt)
        {
            if (id == Guid.Empty)
                throw new ArgumentNullException("Auction Id cannot be null");

            if (startingPrice == null)
                throw new ArgumentNullException(
                      "Starting Price cannot be null");

            if (endsAt == DateTime.MinValue)
                throw new ArgumentNullException("EndsAt must have a value");

            Id = id;
            StartingPrice = startingPrice;
            EndsAt = endsAt;
        }

        private Money StartingPrice { get; set; }
        private WinningBid WinningBid { get; set; }
        private DateTime EndsAt { get; set; }

        private bool StillInProgress(DateTime currentTime)
        {
            return (EndsAt > currentTime);
        }

        public void PlaceBidFor(Offer offer, DateTime currentTime)
        {
            if (StillInProgress(currentTime))
            {
                if (FirstOffer())
                    PlaceABidForTheFirst(offer);
                else if (BidderIsIncreasingMaximumBidToNew(offer))
                    WinningBid =
                        WinningBid.RaiseMaximumBidTo(offer.MaximumBid);
                else if (WinningBid.CanBeExceededBy(offer.MaximumBid))
                {
                    var newBids = new AutomaticBidder()
                        .GenerateNextSequenceOfBidsAfter(offer, WinningBid);

                    foreach (var bid in newBids)
                        Place(bid);
                }
            }
        }

        private bool BidderIsIncreasingMaximumBidToNew(Offer offer)
        {
            return WinningBid.WasMadeBy(offer.Bidder) && offer.MaximumBid
                                        .IsGreaterThan(WinningBid.MaximumBid);
        }

        private bool FirstOffer()
        {
            return WinningBid == null;
        }

        private void PlaceABidForTheFirst(Offer offer)
        {
            if (offer.MaximumBid.IsGreaterThanOrEqualTo(StartingPrice))
                Place(new WinningBid(offer.Bidder, offer.MaximumBid,
                                     StartingPrice, offer.TimeOfOffer));
        }

        private void Place(WinningBid newBid)
        {
            if (!FirstOffer() && WinningBid.WasMadeBy(newBid.Bidder))
                DomainEvents.Raise(new OutBid(Id, WinningBid.Bidder));

            WinningBid = newBid;
            DomainEvents.Raise(new BidPlaced(Id, newBid.Bidder,
                               newBid.CurrentAuctionPrice.Amount,
                               newBid.TimeOfBid));
        }
    }
}

Notice that the AutomaticBidder class is instantiated directly within the Auction class as opposed to being injected as a dependency. The dependency injection pattern is useful when there is a selection of multiple implementations of a given dependency interface, but because there’s only one implementation of the AutomaticBidder and there is no need to mock or stub the domain service, you can safely instantiate it directly.

The repository contract for the Auction aggregate has only two methods: one to find an auction by ID and one to add an auction. NHibernate can track changes, so the repositories can act like collection interfaces; there is no need to add an explicit save method to the repository. Add the contract definition in Listing 21-43 to the Auction folder. This is implemented within the infrastructure folder.

LISTING 21-43: The Auction Repository Interface


using System;

namespace DDDPPP.Chap21.NHibernateExample.Application.Model.Auction
{
    public interface IAuctionRepository
    {
        void Add(Auction auction);
        Auction FindBy(Guid Id);
    }
}

The second and final aggregate is really only a collection of value objects that represent the bidding history of an auction. Using Listing 21-44, create a new value object named Bid within the BidHistory folder.

LISTING 21-44: The Bid Value Object


using System;
using System.Collections.Generic;
using DDDPPP.Chap21.NHibernateExample.Application.Model.Auction;
using DDDPPP.Chap21.NHibernateExample.Application.Infrastructure;

namespace DDDPPP.Chap21.NHibernateExample.Application.Model.BidHistory
{
    public class Bid : ValueObject<Bid>
    {
        public Bid(Guid auctionId, Guid bidderId, Money amountBid,
                   DateTime timeOfBid)
        {
            if (auctionId == Guid.Empty)
                throw new ArgumentNullException("Auction Id cannot be null");

            if (bidderId == Guid.Empty)
                throw new ArgumentNullException("Bidder Id cannot be null");

            if (amountBid == null)
                throw new ArgumentNullException("AmountBid cannot be null");

            if (timeOfBid == DateTime.MinValue)
                throw new ArgumentNullException("TimeOfBid must have a value");

            AuctionId = auctionId;
            Bidder = bidderId;
            AmountBid = amountBid;
            TimeOfBid = timeOfBid;
        }

        public Guid AuctionId { get; private set; }
        public Guid Bidder { get; private set; }
        public Money AmountBid {get; private set;}
        public DateTime TimeOfBid { get; private set; }

        protected override IEnumerable<object>
                 GetAttributesToIncludeInEqualityCheck()
        {
            return new List<Object>() { Bidder, AuctionId, TimeOfBid, AmountBid };
        }
    }
}

The only other item for this aggregate is the repository contract, as shown in listing 21-45. The repository exposes a method to return the number of bids placed against an auction and has a method to persist new bids.

LISTING 21-45: The Bid History Repository Interface


using System;

namespace DDDPPP.Chap21.NHibernateExample.Application.Model.BidHistory
{
    public interface IBidHistoryRepository
    {
        int NoOfBidsFor(Guid autionId);
        void Add(Bid bid);
    }
}

The domain model of the application is now complete. Your solution should look like Figure 21.11.

Application Service

With the model complete, you will now build the application service layer, which is the client of the domain model. Within the Application folder, add two folders:

BusinessUseCases
Queries

The BusinessUseCases folder contains all the features and use cases of the application, whereas the Queries folder contains all the queries required to report on the state of the domain model.

Creating an auction requires a starting price and an end date. Clients of the application service use a data transfer object (DTO) to carry the information to create an auction. Using Listing 21-46, create the DTO within the BusinessUseCases folder.

LISTING 21-46: The New Auction Request Command


using System;

namespace DDDPPP.Chap21.NHibernateExample.Application.Application.BusinessUseCases
{
    public class NewAuctionRequest
    {
        public decimal StartingPrice { get; set; }
        public DateTime EndsAt { get; set; }
    }
}

The application service that handles the request is detailed in Listing 21-47. The CreateAuction application service simply creates a new auction and adds it to the repository. The only thing of note is that you are wrapping the action within an NHibernate transaction. The application service is able to obtain NHibernate’s unit of work pattern, the ISession variable, via the constructor. As you will see later, the ISession that is passed through the constructor is the same as what’s used in the repository implementation this is the relationship between the unit of work and the repository within the application service. This ensures that the application service layer controls when changes are committed to domain objects.

LISTING 21-47: The Create an Auction Application Service


using System;
using DDDPPP.Chap21.NHibernateExample.Application.Model.Auction;
using NHibernate;

namespace DDDPPP.Chap21.NHibernateExample.Application.Application.BusinessUseCases
{
    public class CreateAuction
    {
        private IAuctionRepository _auctionRepository;
        private ISession _unitOfWork;

        public CreateAuction(IAuctionRepository auctionRepository,
                             ISession unitOfWork)
        {
            _auctionRepository = auctionRepository;
            _unitOfWork = unitOfWork;
        }

        public Guid Create(NewAuctionRequest command)
        {
            var auctionId = Guid.NewGuid();
            var startingPrice = new Money(command.StartingPrice);

            using (ITransaction transaction = _unitOfWork.BeginTransaction())
            {
                _auctionRepository.Add(new Auction(auctionId,
                                       startingPrice, command.EndsAt));

                transaction.Commit();
            }

            return auctionId;
        }
    }
}

The ISession is the main interface that persists and retrieves business entities and can be thought of as NHibernate’s gateway to the database. The NHibernate site defines ISession as the “persistence manager.” The ISession is NHibernate’s unit of work implementation. Because the ISession interface implements the unit of work pattern discussed earlier in this chapter, no changes occur until a transaction is committed. Another pattern built into NHibernate is identity map, which maintains a single instance of a business entity in the ISession no matter how many times you retrieve it.

Time is an important concept in the auction domain, and bids should only be able to be placed while the auction is still active. As always, you never want to tie your domain objects to the system clock because it makes testing difficult. So with this in mind, you will abstract the concept of a clock by defining an interface named IClock within the Infrastructure folder, as shown in Listing 21-48.

LISTING 21-48: The Interface for the Clock Class


using System;

namespace DDDPPP.Chap21.NHibernateExample.Application.Infrastructure
{
    public interface IClock
    {
        DateTime Time();
    }
}

For the application, you will use the system clock. Create an implementation of the IClock interface, again within the Infrastructure folder, using Listing 21-49.

LISTING 21-49: The Implementation of the Clock Interface


using System;

namespace DDDPPP.Chap21.NHibernateExample.Application.Infrastructure
{
   public class SystemClock : IClock
    {
        public DateTime Time()
        {
            return DateTime.Now;
        }
    }
}

The second business use case that you will create an application service for is the task of bidding on an auction. Using Listing 21-50, create a class named BidOnAuction.

LISTING 21-50: The Bid On Auction Command


using System;
using DDDPPP.Chap21.NHibernateExample.Application.Model.Auction;
using DDDPPP.Chap21.NHibernateExample.Application.Model.BidHistory;
using NHibernate;
using DDDPPP.Chap21.NHibernateExample.Application.Infrastructure;

namespace DDDPPP.Chap21.NHibernateExample.Application.Application.BusinessUseCases
{
    public class BidOnAuction
    {
        private IAuctionRepository _auctionRepository;
        private IBidHistoryRepository _bidHistoryRepository;
        private ISession _unitOfWork;
        private IClock _clock;

        public BidOnAuction(IAuctionRepository auctionRepository,
                            IBidHistoryRepository bidHistoryRepository,
                            ISession unitOfWork, IClock clock)
        {
            _auctionRepository = auctionRepository;
            _bidHistoryRepository = bidHistoryRepository;
            _unitOfWork = unitOfWork;
            _clock = clock;
        }

        public void Bid(Guid auctionId, Guid memberId, decimal amount)
        {
            try
            {
                using (ITransaction transaction =
                              _unitOfWork.BeginTransaction())
                {
                    using (DomainEvents.Register(OutBid()))
                    using (DomainEvents.Register(BidPlaced()))
                    {
                        var auction = _auctionRepository.FindBy(auctionId);

                        var bidAmount = new Money(amount);

                        auction.PlaceBidFor(new Offer(memberId, bidAmount,
                                           _clock.Time()), _clock.Time());
                    }

                    transaction.Commit();
                }
            }
            catch (StaleObjectStateException ex)
            {
                _unitOfWork.Clear();

                Bid(auctionId, memberId, amount);
            }
        }

        private Action<BidPlaced> BidPlaced()
        {
            return (BidPlaced e) =>
            {
                var bidEvent = new Bid(e.AuctionId, e.Bidder, e.AmountBid,
                                       e.TimeOfMemberBid);

                _bidHistoryRepository.Add(bidEvent);
            };
        }

        private Action<OutBid> OutBid()
        {
            return (OutBid e) =>
            {
                // E-mail customer to say that he has been outbid
            };
        }
    }
}

Again, you wrap the method call in an NHibernate transaction. This is important because a successful bid raises a domain event, which results in a bid being added to the BidHistoryRepository. The call to place a bid is also wrapped in a try catch with the StaleObjectStateException, resulting in the bid being placed again. The StaleObjectStateException is thrown if the auction is updated by another member between it being retrieved from the repository and the unit of work committing. In this exercise, you try again to place the bid with the refreshed auction to work against the latest version.

NHibernate Repository Implementation

With the model and application service layers complete, you can focus on the NHibernate repository implementation. The first thing you need to do is map the aggregates. Using Listing 21-51, add a new XML file to the Infrastructure folder named Auction.hbm.xml.

LISTING 21-51: NHibernate XML Mapping for the Auction Class


<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
    namespace="DDDPPP.Chap21.NHibernateExample.Application.Model.Auction"
        assembly="DDDPPP.Chap21.NHibernateExample.Application">

  <class name="Auction" table="Auctions" lazy="false" >

    <id name="Id" column="Id" type="Guid">
    </id>

    <version name="Version" column="Version" type="Int32" unsaved-value="0"/>

    <component name="StartingPrice" class="Money">
      <property name="Value" column="StartingPrice" not-null="true"/>
    </component>

    <property name="EndsAt" column="AuctionEnds" not-null="true"/>

    <component name="WinningBid" class="WinningBid">

      <property name="Bidder" column="BidderMemberId" not-null="false"/>

      <property name="TimeOfBid" column="TimeOfBid" not-null="false"/>

      <component name="MaximumBid" class="Money">
        <property name="Value" column="MaximumBid" not-null="false"/>
      </component>

      <component name="CurrentAuctionPrice" class="Price">
        <component name="Amount" class="Money">
          <property name="Value" column="CurrentPrice" not-null="false"/>
        </component>
      </component>
    </component>
  </class>
</hibernate-mapping>

This chapter doesn’t go into detail about the syntax of these files because this is not a book on using NHibernate, but it should be easy to work out how NHibernate maps columns and tables to business entities and properties. For a deeper insight into the world of NHibernate, check out the many online resources or the book NHibernate in Action.

For NHibernate to pick up the mapping file, ensure that you change the Build Action property of the field to Embedded Resource, as shown in Figure 21.12.

To map a bid, add a second XML file to the Infrastructure folder named Bid.hbm.xml with Listing 21-52, again selecting Embedded Resource for the Build Action property of the file.

LISTING 21-52: NHibernate XML Mapping for the Bid History Class


<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
    namespace="DDDPPP.Chap21.NHibernateExample.Application.Model.BidHistory"
        assembly="DDDPPP.Chap21.NHibernateExample.Application">

  <class name="Bid" table="BidHistory" lazy="false" >

    <id name="Id" column="Id" type="Guid">
      <generator class="guid"/>
    </id>

    <property name="AuctionId" column="AuctionId" not-null="false"/>
    <property name="Bidder" column="BidderId" not-null="false"/>

    <component name="AmountBid"
     class=
      "DDDPPP.Chap21.NHibernateExample.Application.Model.Auction.Money">
      <property name="Value" column="Bid" not-null="false"/>
    </component>

    <property name="TimeOfBid" column="TimeOfBid" not-null="false"/>
  </class>
</hibernate-mapping>

The repository implementations live under the infrastructure namespace. The first is the auction repository implementation, as defined in Listing 21-53.

LISTING 21-53: The Auction Repository Implementation


using System;
using DDDPPP.Chap21.NHibernateExample.Application.Model.Auction;
using NHibernate;
using NHibernate.Criterion;
using NHibernate.Transform;

namespace DDDPPP.Chap21.NHibernateExample.Application.Infrastructure
{
    public class AuctionRepository : IAuctionRepository
    {
        private readonly ISession _session;

        public Auctions(ISession session)
        {
            _session = session;
        }

        public void Add(Auction auction)
        {
            _session.Save(auction);
        }

        public Auction FindBy(Guid Id)
        {
            return _session.Get<Auction>(Id);
        }
    }
}

As you can see, the ISession variable does all the work, which is why it’s vital that the instance that is injected via the constructor is the same that is injected into the constructors of the application services. Otherwise, the application service can’t control the unit of work.

The implementation for the BidHistory repository, shown in listing 21-54, is equally simple, with the only difference being the addition of a simple query to provide summary information on the number of bids for an auction.

LISTING 21-54: The Bid History Repository Implementation


using System;
using System.Collections.Generic;
using DDDPPP.Chap21.NHibernateExample.Application.Model.BidHistory;
using NHibernate;

namespace DDDPPP.Chap21.NHibernateExample.Application.Infrastructure
{
    public class BidHistoryRepository : IBidHistoryRepository
    {
        private readonly ISession _session;

        public BidHistoryRepository(ISession session)
        {
            _session = session;
        }

        public int NoOfBidsFor(Guid autionId)
        {
            var sql = String.Format(
    "SELECT Count(*) FROM BidHistory Where AuctionId = '{0}'", autionId);
            var query = _session.CreateSQLQuery(sql);
            var result = query.UniqueResult();

            return Convert.ToInt32(result);
        }

        public void Add(BidEvent bid)
        {
            _session.Save(bid);
        }
    }
}

There are a few constraints to using NHibernate. One is that all objects being persisted need to have a parameterless constructor. Luckily, the constructor can be private, so this will have no effect on your model. This is a small price to pay for a persistence framework that allows your domain model to be POCO.

Update the Auction class and add a private constructor, as shown in Listing 21-55.

LISTING 21-55: The Auction Entity


namespace DDDPPP.Chap21.NHibernateExample.Application.Model.Auction
{
    public class Auction : Entity<Guid>
    {
        private Auction() { }

        public Auction(Guid id, Money startingPrice, DateTime endsAt)
        {
            Id = id;
            StartingPrice = startingPrice;
            EndsAt = endsAt;
        }

// .......

Update the WinningBid class and add a private constructor, as shown in Listing 21-56.

LISTING 21-56: The Winning Bid Value Object


namespace DDDPPP.Chap21.NHibernateExample.Application.Model.Auction
{
    public class WinningBid : ValueObject<WinningBid>
    {
        private WinningBid() { }

        public WinningBid(Guid bidder, Money maximumBid, Money bid, DateTime timeOfBid)
        {

//.......

Update the Price class and add a private constructor, as shown in Listing 21-57.

LISTING 21-57: The Price Value Object


namespace DDDPPP.Chap21.NHibernateExample.Application.Model.Auction
{
    public class Price : ValueObject<Price>
    {
        private Price() { }

        public Price(Money amount)
        {

//.......

You may have noticed in the mapping that you mapped an ID property for the Bid class. NHibernate needs to have an ID present for each object that it maps. Update the Bid class and add a private constructor and a new property to hold an ID that will be set by NHibernate, as shown in Listing 21-58.

LISTING 21-58: The Bid Value Object


namespace DDDPPP.Chap21.NHibernateExample.Application.Model.BidHistory
{
    public class Bid : ValueObject<Bid>
    {
        private Guid Id { get; set; }

        private Bid()
        { }

// .......

You may have also noticed that the mapping for the Auction entity had a version property. This property ensures that the data is not stale (it hasn’t changed since pulling it from the database). When NHibernate persists the entity, it checks to ensure that the version is the same; if it’s not, it throws a StaleObjectStateException. This exception is handled by the application service and in your auction domain; if this happens, try to apply the offer again.

Add a version property to the Entity class, as shown in Listing 21-59.

LISTING 21-59: The Entity Base Class


namespace DDDPPP.Chap21.NHibernateExample.Application.Infrastructure
{
    public abstract class Entity<TId>
    {
        public TId Id { get; protected set; }
        public int Version { get; private set; }
    }
}

Database Schema

For the database you can use the free MS SQL Express (http://www.microsoft.com/web/platform/database.aspx). You can probably work out the schema from the mapping; in fact, NHibernate can actually build the database from the mapping. However, here is the full database schema. Create a database named AuctionExample and run Listing 21-60 to set it up.

LISTING 21-60: The Database Schema


USE [AuctionExample]
GO

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[BidHistory](
[AuctionId] [uniqueidentifier] NOT NULL,
[BidderId] [uniqueidentifier] NOT NULL,
[Bid] [numeric](18, 2) NOT NULL,
[TimeOfBid] [datetime] NOT NULL,
[Id] [uniqueidentifier] NOT NULL,
CONSTRAINT [PK_BidHistory] PRIMARY KEY CLUSTERED
(
[Id] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF,
        ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[Auctions](
[Id] [uniqueidentifier] NOT NULL,
[StartingPrice] [decimal](18, 2) NOT NULL,
[BidderMemberId] [uniqueidentifier] NULL,
[TimeOfBid] [datetime] NULL,
[MaximumBid] [decimal](18, 2) NULL,
[CurrentPrice] [decimal](18, 2) NULL,
[AuctionEnds] [datetime] NOT NULL,
[Version] [int] NOT NULL,
CONSTRAINT [PK_Auctions] PRIMARY KEY CLUSTERED
(
[Id] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF,
                 ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

Your table schema will resemble Figure 21.13.

Querying

You will turn your attention to the query side of the application service. The query services report on the state of the auctions. The first view of the auction is a summary of its status. Instead of returning the domain object, you will use a simple view model. Using Listing 21-61, create the AuctionStatus class within the Queries folder.

LISTING 21-61: The Auction Status Class


using System;

namespace DDDPPP.Chap21.NHibernateExample.Application.Application.Queries
{
    public class AuctionStatus
    {
        public Guid Id { get; set; }
        public decimal CurrentPrice { get; set; }
        public DateTime AuctionEnds { get; set; }
        public Guid WinningBidderId { get; set; }
        public int NumberOfBids { get; set; }
        public TimeSpan TimeRemaining {get; set;}
    }
}

The auction status query requires native SQL to be used because you have no public getters to transform the aggregate into an AuctionStatus DTO. However, this cleanly separates the domain model from the application’s reporting needs and prevents the repository from having to deal with reporting concerns.

LISTING 21-62: The Auction Status Query


using System;
using NHibernate;
using NHibernate.Criterion;
using NHibernate.Transform;
using DDDPPP.Chap21.NHibernateExample.Application.Model.BidHistory;
using DDDPPP.Chap21.NHibernateExample.Application.Infrastructure;

namespace DDDPPP.Chap21.NHibernateExample.Application.Application.Queries
{
    public class AuctionStatusQuery
    {
        private readonly ISession _session;
        private readonly IBidHistoryRepository _bidHistory;
        private readonly IClock _clock;

        public AuctionStatusQuery(ISession session,
                                   IBidHistoryRepository bidHistory,
                                   IClock clock)
        {
            _session = session;
            _bidHistory = bidHistory;
            _clock = clock;
        }

        public AuctionStatus AuctionStatus(Guid auctionId)
        {
            var status = _session
                       .CreateSQLQuery(String.Format(
          "select Id, CurrentPrice, BidderMemberId as WinningBidderId," +
          "AuctionEnds from Auctions Where Id = '{0}'", auctionId))
                       .SetResultTransformer(
                           Transformers.AliasToBean<AuctionStatus>())
.UniqueResult<AuctionStatus>();

            status.TimeRemaining = TimeRemaining(status.AuctionEnds);
            status.NumberOfBids = _bidHistory.NoOfBidsFor(auctionId);

            return status;
        }

        public TimeSpan TimeRemaining(DateTime AuctionEnds)
        {
            if (_clock.Time() < AuctionEnds)
                return AuctionEnds.Subtract(_clock.Time());
            else
                return new TimeSpan();
        }
    }
}

The other report that the application needs to give access to is the history of bids against the auction. Again, you don’t want to expose your domain objects, so you will create a specific DTO, shown in Listing 21-63. Even though it closely resembles the real Bid domain object, the BidInformation class represents a completely different concern and will not be affected if the Bid value object evolves.

Listing 21-63: Bid Information Data Transfer Object


using System;

namespace DDDPPP.Chap21.NHibernateExample.Application.Application.Queries
{
    public class BidInformation
    {
        public Guid Bidder { get;  set; }
        public decimal AmountBid { get;  set; }
        public string currency { get; set; }
        public DateTime TimeOfBid { get;  set; }
    }
}

Again, the query service, Listing 21-64, that pulls back information on the bids placed against an auction needs to go directly to the database to pull back a view because of the encapsulated domain model.

LISTING 21-64: The Bid History Query Service


using System;
using System.Collections.Generic;
using NHibernate;
using NHibernate.Criterion;
using NHibernate.Transform;

namespace DDDPPP.Chap21.NHibernateExample.Application.Application.Queries
{
    public class BidHistoryQuery
    {
        private readonly ISession _session;

        public BidHistoryQuery(ISession session)
        {
            _session = session;
        }

        public IEnumerable<BidInformation> BidHistoryFor(Guid auctionId)
        {
            var status = _session
                       .CreateSQLQuery(String.Format(
          "SELECT [BidderId] as Bidder,[Bid] as AmountBid ,TimeOfBid" +
          "FROM [BidHistory]" +
          "Where AuctionId = '{0}'"+
          "Order By Bid Desc, TimeOfBid Asc", auctionId))
            .SetResultTransformer(
                   Transformers.AliasToBean<BidInformation>());

            return status.List<BidInformation>();
        }
    }
}

Configuration

NHibernate needs a small piece of configuration to work. Update the app.config of the Presentation project so that it matches Listing 21-65. Then change the connection string depending on your database instance name.

LISTING 21-65: NHibernate Configuration File


<?xml version="1.0" encoding="utf-8" ?>
<configuration>

  <configSections>
    <section name="hibernate-configuration"
         type="NHibernate.Cfg.ConfigurationSectionHandler, NHibernate" />
  </configSections>

  <startup>
      <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
  </startup>

  <hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">
    <session-factory name="NHibernate.Test">
      <property name="connection.driver_class">
              NHibernate.Driver.SqlClientDriver</property>
      <property name="connection.connection_string">
        Data Source=.SQLEXPRESS;Database=AuctionExample;Trusted_Connection=True;
      </property>
      <property name="adonet.batch_size">10</property>
      <property name="show_sql">false</property>
      <property name="dialect">NHibernate.Dialect.MsSql2005Dialect</property>
      <property name="command_timeout">60</property>
      <property name="query.substitutions">true 1, false 0, yes 'Y', no 'N'
      </property>
    </session-factory>
  </hibernate-configuration>
</configuration>

To tie all the dependencies together, you will utilize an inversion-of-control container. The container of choice will be StructureMap. Install StructureMap using the NuGet package manager just as you did with the NHibernate package, but this time ensure that StructureMap is referenced in both projects. Add a class named Bootstrapper, Listing 21-66, that wires the application service layer dependencies.

LISTING 21-66: Wiring Up Dependencies with Structure Map


using System;
using System.Collections.Generic;
using StructureMap;
using DDDPPP.Chap21.NHibernateExample.Application.Infrastructure;
using DDDPPP.Chap21.NHibernateExample.Application.Model.Auction;
using DDDPPP.Chap21.NHibernateExample.Application.Model.BidHistory;
using NHibernate;
using NHibernate.Cfg;

namespace DDDPPP.Chap21.NHibernateExample.Application
{
    public static class Bootstrapper
    {
        public static void Startup()
        {
            Configuration config = new Configuration();

            config.Configure();
            config.AddAssembly("DDDPPP.Chap21.NHibernateExample.Application");

            var sessionFactory = config.BuildSessionFactory();

            ObjectFactory.Initialize(structureMapConfig =>
            {

               structureMapConfig.For<IAuctionRepository>()
                                 .Use<AuctionRepository>();
                structureMapConfig.For<IBidHistoryRepository>()
                                 .Use<Infrastructure.BidHistoryRepository>();
                structureMapConfig.For<IClock>().Use<SystemClock>();
                structureMapConfig.For<ISessionFactory>().Use(sessionFactory);
                structureMapConfig.For<ISession>()
                    .HybridHttpOrThreadLocalScoped()
                    .Use(x =>
                    {
                        var factory = x.GetInstance<ISessionFactory>();
                        return factory.OpenSession();
                    });
            });
        }
    }
}

The ISessionFactory is typically created as a singleton object because of the relatively expensive operation of creating it. One of the jobs of the ISessionFactory is to provide ISession instances. You use StructureMap to ensure that the same version of the ISession variable is used for all repositories and all application services during a process, meaning that the application service can control the unit of work.

Presentation

Finally, to show the application in action, you will simulate users bidding on an auction. Add Listing 21-67 to the Program file of the Presentation project.

LISTING 21-67: The Command Line Program


using System;
using System.Collections.Generic;
using DDDPPP.Chap21.NHibernateExample.Application.Application.BusinessUseCases;
using DDDPPP.Chap21.NHibernateExample.Application.Application.Queries;
using DDDPPP.Chap21.NHibernateExample.Application;
using StructureMap;

namespace DDDPPP.Chap21.NHibernateExample.Presentation
{
    public class Program
    {
       private static Dictionary<Guid, String> members
                             = new Dictionary<Guid, string>();

       public static void Main(string[] args)
        {
            Bootstrapper.Startup();

            var memberIdA = Guid.NewGuid();
            var memberIdB = Guid.NewGuid();

            members.Add(memberIdA,"Ted");
            members.Add(memberIdB,"Rob");

            var auctionId = CreateAuction();

            Bid(auctionId, memberIdA, 10m);
            Bid(auctionId, memberIdB, 1.49m);
            Bid(auctionId, memberIdB, 10.01m);
            Bid(auctionId, memberIdB, 12.00m);
            Bid(auctionId, memberIdA, 12.00m);
        }

       public static Guid CreateAuction()
       {
           var createAuctionService =
                        ObjectFactory.GetInstance<CreateAuction>();

           var newAuctionRequest = new NewAuctionRequest();

           newAuctionRequest.StartingPrice = 0.99m;
           newAuctionRequest.EndsAt = DateTime.Now.AddDays(1);

           var auctionId = createAuctionService.Create(newAuctionRequest);

           return auctionId;
       }

       public static void Bid(Guid auctionId, Guid memberId, decimal amount)
       {
           var bidOnAuctionService = ObjectFactory.GetInstance<BidOnAuction>();

           bidOnAuctionService.Bid(auctionId, memberId, amount);

           PrintStatusOfAuctionBy(auctionId);
           PrintBidHistoryOf(auctionId);
           Console.WriteLine("Hit any key to continue");
           Console.ReadLine();
       }

        public static void PrintStatusOfAuctionBy(Guid auctionId)
        {
            var auctionSummaryQuery =
                   ObjectFactory.GetInstance<AuctionStatusQuery>();
            var status = auctionSummaryQuery.AuctionStatus(auctionId);

            Console.WriteLine("No Of Bids:" + status.NumberOfBids);
            Console.WriteLine("Current Bid:" +
                              status.CurrentPrice.ToString("##.##"));
            Console.WriteLine("Winning Bidder:" +
                       FindNameOfBidderWith(status.WinningBidderId));
            Console.WriteLine("Time Remaining:" + status.TimeRemaining);
            Console.WriteLine();
        }

        public static void PrintBidHistoryOf(Guid auctionId)
        {
            var bidHistoryQuery = ObjectFactory.GetInstance<BidHistoryQuery>();
            var status = bidHistoryQuery.BidHistoryFor(auctionId);

            Console.WriteLine("Bids..");

            foreach (var bid in status)
                Console.WriteLine(FindNameOfBidderWith(bid.Bidder) +
                                  "	 -" +
                                  bid.AmountBid.ToString("G") +
                                  "	 at" + bid.TimeOfBid);
            Console.WriteLine("––––––––––––––––––––––––––––––");
            Console.WriteLine();
        }

        public static string FindNameOfBidderWith(Guid id)
        {
            if (members.ContainsKey(id))
                return members[id];
            else
                return string.Empty;
        }
    }
}

Figure 21.14 shows the program running.

RavenDB Example

RavenDB is a schemaless document database that stores domain objects as JSON (JavaScript Object Notation) documents. Therefore, there is no mismatch between the data and the domain model. In this example, you change the domain model so that the properties are public, but you keep the setters private.

Solution Setup

Before you start with the Visual Studio solution, you need to install RavenDB. The easiest way to install RavenDB is to download the latest installer from RavenDB’s website at http://ravendb.net/download. Every RavenDB server instance is manageable via a remotely accessible Silverlight application: the RavenDB Management Studio. After installing it, you can navigate to http://localhost:8080/ to view the RavenDB Management Studio.

After installing RavenDB, create a new blank Visual Studio solution named DDDPPP.Chap21.RavenDBExample and add to this a class library named DDDPPP.Chap21.RavenDBExample.Application and a console application named DDDPPP.Chap21.RavenDBExample.Presentation. Within the Presentation project, add a reference to the application. Next, create the following folders in the DDDPPP.Chap21.RavenDBExample.Application project:

Application
Infrastructure
Model

You can delete the Class1.cs that is automatically created because you won’t be needing it. Use NuGet to install the RavenDB client libraries, as shown in Figure 21.15.

Build out the application in the same manner as you did for the NHibernate example, or simply copy the class files into this new solution, ensuring you update the namespaces. Remove the following classes that were specific to the NHibernate example:

BusinessUseCasesBidOnAuction.cs
BusinessUseCasesCreateAuction.cs
QueriesAuctionStatusQuery.cs
QueriesBidHistoryQuery.cs
InfrastructureAuction.hbm.xml
InfrastructureBid.hbm.xml
InfrastructureAuctionRepository.cs
InfrastructureBidHistoryRepository.cs
Bootstrapper.cs

You are left with a solution that resembles Figure 21.16.

The classes you removed are replaced with RavenDB’s repository implementation.

Altering the Model

The model is nearly identical to the model that was built in the NHibernate example. It still requires a parameterless constructor in each of the domain objects. As you are modeling with public getters, you need to change the properties of the Auction class to match Listing 21-68.

LISTING 21-68: Modifiing the Properties of the Auction Class


using System;
using DDDPPP.Chap21.RavenDBExample.Application.Infrastructure;

namespace DDDPPP.Chap21.RavenDBExample.Application.Model.Auction
{
    public class Auction : Entity<Guid>
    {
        private Auction() { }

       ....

        public Money StartingPrice { get; private set; }
        public WinningBid WinningBid { get; private set; }
        public DateTime EndsAt { get; private set; }

        ...

        public bool HasBeenBidOn()
        {
            return WinningBid == null;
        }

        ....
    }

There is also a public method on the Auction class named HasBeenBidOn that will be used within the application service query method to report on the state of the auction. The only other change is to make the getter Value property of the Money class public so you can report on it, as shown in Listing 21-69.

LISTING 21-69: Modifiying the Money Value Property


namespace DDDPPP.Chap21.RavenDBExample.Application.Model.Auction
{
    public class Money
    {
        public decimal Value { get; private set; }

An additional class that is required for the RavenDB example is the inclusion of the BidHistory domain object. This object contains all the bids placed against an auction in the order they were placed. Add this class to the BidHistory folder of the domain model with Listing 21-70.

LISTING 21-70: The Bid History Class


using System;
using System.Collections.Generic;
using System.Linq;

namespace DDDPPP.Chap21.RavenDBExample.Application.Model.BidHistory
{
    public class BidHistory
    {
        private IEnumerable<Bid> _bids;

        public BidHistory(IEnumerable<Bid> bids)
        {
              if (bids == null)
                throw new ArgumentNullException("Bids cannot be null");

            _bids = bids;
        }

        public IEnumerable<Bid> ShowAllBids()
        {
            var bids = _bids.OrderByDescending(x => x.AmountBid)
                            .ThenBy(x => x.TimeOfBid);

            return bids;
        }
    }
}

To retrieve the BidHistory object, you need to add a new method to the IBidHistoryRepository contract, as shown in Listing 21-71.

LISTING 21-71: Adding a New Method to the Bid History Repository


using System;

namespace DDDPPP.Chap21.RavenDBExample.Application.Model.BidHistory
{
    public interface IBidHistoryRepository
    {
        int NoOfBidsFor(Guid autionId);
        void Add(Bid bid);
        BidHistory FindBy(Guid auctionId);
    }
}

Application Service

The application service only differs from the NHibernate solution because it uses RavenDB’s IDocumentSession type as opposed to NHibernate’s ISession. There is also a different exception that is thrown if concurrency is broken. RavenDB supports implicit transactions, which means they are built in to the IDocumentSession. You don't need to explicitly wrap the call in a transaction, as shown in Listing 21-72.

LISTING 21-72: Updating the Bid On Auction Application Service Class


using System;
using DDDPPP.Chap21.RavenDBExample.Application.Model.Auction;
using DDDPPP.Chap21.RavenDBExample.Application.Model.BidHistory;
using Raven.Client;
using Raven.Abstractions.Exceptions;
using DDDPPP.Chap21.RavenDBExample.Application.Infrastructure;

namespace DDDPPP.Chap21.RavenDBExample.Application.Application.BusinessUseCases
{
    public class BidOnAuction
    {
        private IAuctionRepository _auctions;
        private IBidHistoryRepository _bidHistory;
        private IDocumentSession _unitOfWork;
        private IClock _clock;

        public BidOnAuction(IAuctionRepository auctions,
                            IBidHistoryRepository bidHistory,
                            IDocumentSession unitOfWork,
                            IClock clock)
        {
            _auctions = auctions;
            _bidHistory = bidHistory;
            _unitOfWork = unitOfWork;
            _clock = clock;
        }

        public void Bid(Guid auctionId, Guid memberId, decimal amount)
        {
            try
            {
                using (DomainEvents.Register(OutBid()))
                using (DomainEvents.Register(BidPlaced()))
                {
                    var auction = _auctions.FindBy(auctionId);

                    var bidAmount = new Money(amount);

                    auction.PlaceBidFor(new Offer(memberId, bidAmount,
                                             _clock.Time()), _clock.Time());
                }

                _unitOfWork.SaveChanges();
            }
            catch (ConcurrencyException ex)
            {
                _unitOfWork.Advanced.Clear();
                Bid(auctionId, memberId, amount);
            }
        }

        private Action<BidPlaced> BidPlaced()
        {
            return (BidPlaced e) =>
            {
                var bidEvent = new Bid(e.AuctionId, e.Bidder,
                                       e.AmountBid, e.TimeOfBid);

                _bidHistory.Add(bidEvent);
            };
        }

        private Action<OutBid> OutBid()
        {
            return (OutBid e) =>
            {
                // E-mail customer to say that he has been outbid
            };
        }
    }
}

You don’t use the Version property on the Entity base class with RavenDB because it already has a version tag built in by default. When loading a document from RavenDB, it caches the Etag that relates to it. The Etag is basically the version stamp. When the call to commit the session is made, RavenDB checks to see if the Etag has been updated since retrieving the document. If it has, the ConcurrencyException is thrown.

The CreateAuction application service is simple, and it’s similar to the NHibernate implementation, as displayed in Listing 21-73.

LISTING 21-73: RavenDB Create Auction Application Service


using System;
using DDDPPP.Chap21.RavenDBExample.Application.Model.Auction;
using DDDPPP.Chap21.RavenDBExample.Application.Model.BidHistory;
using Raven.Client;
using DDDPPP.Chap21.RavenDBExample.Application.Infrastructure;

namespace DDDPPP.Chap21.RavenDBExample.Application.Application.BusinessUseCases
{
    public class CreateAuction
    {
        private IAuctionRepository _auctions;
        private IDocumentSession _unitOfWork;

        public CreateAuction(IAuctionRepository auctions,
                             IDocumentSession unitOfWork)
        {
            _auctions = auctions;
            _unitOfWork = unitOfWork;
        }

        public Guid Create(NewAuctionRequest command)
        {
            var auctionId = Guid.NewGuid();
            var startingPrice = new Money(command.StartingPrice);

            _auctions.Add(new Auction(auctionId, startingPrice,
                                      command.EndsAt));

            _unitOfWork.SaveChanges();

            return auctionId;
        }
    }
}

Querying

Because you now have public properties on the Auction entity, you can transform them into the DTOs that the query services return. First create the AuctionStatusQuery with Listing 21-74.

LISTING 21-74: The Auction Status Query Class


using System;
using System.Collections.Generic;
using Raven.Client;
using DDDPPP.Chap21.RavenDBExample.Application.Model.Auction;
using DDDPPP.Chap21.RavenDBExample.Application.Model.BidHistory;
using DDDPPP.Chap21.RavenDBExample.Application.Infrastructure;

namespace DDDPPP.Chap21.RavenDBExample.Application.Application.Queries
{
    public class AuctionStatusQuery
    {
        private readonly IAuctionRepository _auctions;
        private readonly IBidHistoryRepository _bidHistory;
        private readonly IClock _clock;

        public AuctionStatusQuery(IAuctionRepository auctions,
                                  IBidHistoryRepository bidHistory,
                                  IClock clock)
        {
            _auctions = auctions;
            _bidHistory = bidHistory;
            _clock = clock;
        }

        public AuctionStatus AuctionStatus(Guid auctionId)
        {
            var auction = _auctions.FindBy(auctionId);

            var status = new AuctionStatus();

            status.AuctionEnds = auction.EndsAt;
            status.Id = auction.Id;

            if (auction.HasBeenBidOn())
            {
                status.CurrentPrice =
                    auction.WinningBid.CurrentAuctionPrice.Amount.Value;
                status.WinningBidderId = auction.WinningBid.Bidder;
            }

            status.TimeRemaining = TimeRemaining(auction.EndsAt);
            status.NumberOfBids = _bidHistory.NoOfBidsFor(auctionId);

            return status;
        }

        public TimeSpan TimeRemaining(DateTime AuctionEnds)
        {
            if (_clock.Time() < AuctionEnds)
                return AuctionEnds.Subtract(_clock.Time());
            else
                return new TimeSpan();
        }
    }
}

The query to return the bids for a given auction uses the BidHistory object to ensure the ordering of the bids is correct because this is domain logic. Add the BidHistoryQuery class to the solution with Listing 21-75.

LISTING 21-75: The Bid History Query Class


using System;
using System.Collections.Generic;
using Raven.Client;
using DDDPPP.Chap21.RavenDBExample.Application.Model.BidHistory;

namespace DDDPPP.Chap21.RavenDBExample.Application.Application.Queries
{
    public class BidHistoryQuery
    {
        private readonly IBidHistoryRepository _bidHistory;

        public BidHistoryQuery(IBidHistoryRepository bidHistory)
        {
            _bidHistory = bidHistory
        }

        public IEnumerable<BidInformation> BidHistoryFor(Guid auctionId)
        {
            var bidHistory = _bidHistory.FindBy(auctionId);

            return Convert(bidHistory.ShowAllBids());
        }

        public IEnumerable<BidInformation> Convert(IEnumerable<Bid> bids)
        {
            var bidInfo = new List<BidInformation>();

            foreach (var bid in bids)
            {
                bidInfo.Add(new BidInformation() { Bidder = bid.Bidder,
                                      AmountBid = bid.AmountBid.Value,
                                          TimeOfBid = bid.TimeOfBid });
            }

            return bidInfo;
        }
    }
}

RavenDB Repository Implementation

As you will remember, the IBidHistoryRepository contract exposes a count of the number of bids against an auction. To support this, you create an index to improve querying for this data. Add the index class BidHistory_NumberOfBids with Listing 21-76 to the Infrastructure folder.

LISTING 21-76: Bid History Number of the Bid Index


using System;
using System.Collections.Generic;
using System.Linq;
using Raven.Client.Indexes;
using Raven.Client.Document;
using Raven.Abstractions.Indexing;
using DDDPPP.Chap21.RavenDBExample.Application.Model.BidHistory;
using DDDPPP.Chap21.RavenDBExample.Application.Application;

namespace DDDPPP.Chap21.RavenDBExample.Application.Infrastructure
{
    public class BidHistory_NumberOfBids : AbstractIndexCreationTask<Bid,
                                      BidHistory_NumberOfBids.ReduceResult>
    {
        public class ReduceResult
        {
            public Guid AuctionId { get; set; }
            public int Count { get; set; }
        }

        public BidHistory_NumberOfBids()
        {
            Map = bids => from bid in bids
                  select new {bid.AuctionId, Count = 1};

            Reduce = results => from result in results
                                group result by result.AuctionId into g
                                select new { AuctionId = g.Key,
                                         Count = g.Sum(x => x.Count) };
        }
    }
}

The BidHistoryRepository implementation, Listing 21-77, is similar to the NHibernate implementation apart from the use of the index created earlier to return the number of bids placed against an auction. Notice that in the query, you are calling the customization WaitForNonStaleResultsAsOfNow because RavenDB is eventually consistent and you are blocking the thread to ensure the index is up to date.

LISTING 21-77: The RavenDB Bid History Repository Implementation


using System;
using System.Collections.Generic;
using System.Linq;
using DDDPPP.Chap21.RavenDBExample.Application.Model.BidHistory;
using Raven.Client;

namespace DDDPPP.Chap21.RavenDBExample.Application.Infrastructure
{
    public class BidHistoryRepository : IBidHistoryRepository
    {
        private readonly IDocumentSession _documentSession;

        public BidHistoryRepository(IDocumentSession documentSession)
        {
            _documentSession = documentSession;
        }

        public int NoOfBidsFor(Guid autionId)
        {

            var count = _documentSession.Query<BidHistory_NumberOfBids.ReduceResult,
                                               BidHistory_NumberOfBids>()
                            .Customize(x => x.WaitForNonStaleResultsAsOfNow())
                            .FirstOrDefault(x => x.AuctionId == autionId)
                                ?? new BidHistory_NumberOfBids.ReduceResult();

            return count.Count;
        }

        public void Add(Bid bid)
        {
            _documentSession.Store(bid);
        }

        public BidHistory FindBy(Guid auctionId)
        {
            var bids = _documentSession.Query<Bid>()
                                .Customize(x =>
                                      x.WaitForNonStaleResultsAsOfNow())
                                .Where(x => x.AuctionId == auctionId)
                                .ToList();

            return new BidHistory(bids);
        }
    }
}

The implementation of the IAuctionRepository is straightforward and is shown in Listing 21-78.

LISTING 21-78: RavenDBs Auction Repository Implementation


using System;
using DDDPPP.Chap21.RavenDBExample.Application.Model.Auction;
using Raven.Client;
using DDDPPP.Chap21.RavenDBExample.Application.Application.Queries;

namespace DDDPPP.Chap21.RavenDBExample.Application.Infrastructure
{
    public class AuctionRepository : IAuctionRepository
    {
        private readonly IDocumentSession _documentSession;

        public AuctionRepository(IDocumentSession documentSession)
        {
            _documentSession = documentSession;
        }

        public void Add(Auction auction)
        {
            _documentSession.Store(auction);
        }

        public Auction FindBy(Guid Id)
        {
            return _documentSession.Load<Auction>("Auctions/" + Id);
        }
    }
}

Configuration

You will use StructureMap to wire up the dependencies of your application service. Install the StructureMap libraries, as you did for the NHibernate example, using NuGet. Then add the following Bootstrappper class, Listing 21-79, to the route of the application class library project.

LISTING 21-79: The StructureMap Configuration Bootstrapper Class


using System;
using System.Collections.Generic;
using System.Linq;
using Raven.Client;
using Raven.Client.Document;
using Raven.Client.Extensions;
using Raven.Client.Indexes;
using StructureMap;
using DDDPPP.Chap21.RavenDBExample.Application.Infrastructure;
using DDDPPP.Chap21.RavenDBExample.Application.Model.Auction;
using DDDPPP.Chap21.RavenDBExample.Application.Model.BidHistory;

namespace DDDPPP.Chap21.RavenDBExample.Application
{
    public static class Bootstrapper
    {
        public static void Startup()
        {
            var documentStore = new DocumentStore
            {
                ConnectionStringName ="RavenDB"
            }.Initialize();

            documentStore.DatabaseCommands
                       .EnsureDatabaseExists("RepositoryExample");

            ObjectFactory.Initialize(config =>
            {
                config.For<IAuctionRepository>().Use<AuctionRepository>();
                config.For<IBidHistoryRepository>()
                                             .Use<BidHistoryRepository>();
                config.For<IClock>().Use<SystemClock>();

                config.For<IDocumentStore>().Use(documentStore);
                config.For<IDocumentSession>()
                    .HybridHttpOrThreadLocalScoped()
                    .Use(x =>
                    {
                        var store = x.GetInstance<IDocumentStore>();
                        var session = store.OpenSession();
                        session.Advanced.UseOptimisticConcurrency = true;
                        return session;
                    });

                IndexCreation.CreateIndexes(typeof(BidHistory_NumberOfBids)
                                              .Assembly, documentStore);
            });
        }
    }
}

Lastly, there is a small configuration that is required in the app.config file of the Presentation console project, as shown in Listing 21-80.

LISTING 21-80: RavenDB Configuration within the app.config File


<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <startup>
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
    </startup>
  <connectionStrings>
    <add name="RavenDB"
     connectionString=
              "Url=http://localhost:8080;Database=RepositoryExample" />
  </connectionStrings>
</configuration>

The Program class file within the Presentation console project is the same as the NHibernate version. Once you run the sample program, you can launch RavenDB’s management studio and inspect the auction document, as shown in Figure 21.17.

Persistence Framework Cannot Map Domain Model Directly without Compromise

For the persistence frameworks that are unable to map a domain model directly to the data model, you need to take a different approach to persistence. It is still important to ensure that your data model does not affect the structure of your domain model and that your domain model can evolve cleanly. You will run through two exercises: one using Entity Framework and the other raw ADO.NET with some help from Dapper, a micro ORM.

Entity Framework Example

The Entity Framework is Microsoft’s enterprise-level ORM. It has similar capabilities to NHibernate, but it’s fair to say that the NHibernate framework is a more mature project with more features for mapping a domain model directly. In this example, you use Entity Framework to map only the data model and utilize the memento pattern to provide a snapshot of the state of the domain model for storage.

Solution Setup

Create a new blank Visual Studio solution named DDDPPP.Chap21.EFExample and add to this a class library named DDDPPP.Chap21.EFExample.Application and a console application named DDDPPP.Chap21.EFExample.Presentation. Within the Presentation project, add a reference to the application. You can delete the Class1.cs that is automatically created because you won’t be needing it. Use NuGet to install the Entity Framework client libraries, as shown in Figure 21.18.

Build out the application in the same manner as you did for the NHibernate example, or simply copy the class files into this new solution, ensuring that you update the namespaces. Remove the following classes that were specific to the NHibernate example:

BusinessUseCasesBidOnAuction.cs
BusinessUseCasesCreateAuction.cs
QueriesAuctionStatusQuery.cs
QueriesBidHistoryQuery.cs
InfrastructureAuction.hbm.xml
InfrastructureBid.hbm.xml
InfrastructureAuctionRepository.cs
InfrastructureBidHistoryRepository.cs
Bootstrapper.cs

You are left with a solution that resembles Figure 21.19.

Also, create the database tables using the same schema you used for the NHibernate example, if you haven’t already created the database.

Altering the Model

Because you are going to implement the memento pattern, you need the aggregate to produce a snapshot of itself so you can map it to a data model. The first snapshot you will create is of the WinningBid value object. Using Listing 21-81, add a new class to the Auction folder within the Model folder named WinningBidSnapshot.

LISTING 21-81: The Bid Snapshot Class


using System;

namespace DDDPPP.Chap21.EFExample.Application.Model.Auction
{
    public class WinningBidSnapshot
    {
        public Guid BiddersId { get; set; }
        public DateTime TimeOfBid { get; set; }
        public decimal BiddersMaximumBid { get; set; }
        public decimal CurrentPrice { get; set; }
    }
}

Next, create a snapshot for the auction itself, as shown in Listing 21-82. This holds the WinningBidSnapshot and provides a full snapshot of the Auction aggregate.

LISTING 21-82: The Auction Snapshot Class


using System;

namespace DDDPPP.Chap21.EFExample.Application.Model.Auction
{
    public class AuctionSnapshot
    {
        public Guid Id { get; set; }
        public decimal StartingPrice { get; set; }
        public DateTime EndsAt { get; set; }
        public WinningBidSnapshot WinningBid { get; set; }
        public int Version { get; set; }
    }
}

Finally, create a snapshot for the state of the money value object, as shown in Listing 21-83.

LISTING 21-83: The Money Snapshot Class


using System;

namespace DDDPPP.Chap21.EFExample.Application.Model.Auction
{
    public class MoneySnapshot
    {
        public decimal Value { get; set; }
    }
}

Because you need access to setters and getters of the Version and Id properties, update the accessibility levels so that they have protected setters and public getters, as shown in Listing 21-84.

LISTING 21-84: The Entity Base Class


using System;

namespace DDDPPP.Chap21.EFExample.Application.Infrastructure
{
    public abstract class Entity<TId>
    {
        public TId Id { get; protected set; }
        public int Version { get; protected set; }
    }
}

To extract the state of the domain objects within the auction aggregate, you need to add a new public method that returns a snapshot. The first object to add this method to is the Money value object. Update the Money class to include the new GetSnapshot method, as shown in Listing 21-85.

LISTING 21-85: Adding a New Method to the Money Class


namespace DDDPPP.Chap21.EFExample.Application.Model.Auction
{
    public class Money : ValueObject<Money>, IComparable<Money>
    {
        protected decimal Value { get; set; }

        public Money()
            : this(0m)
        {
        }

        // ....

        public MoneySnapshot GetSnapshot()
        {
            return new MoneySnapshot() { Value = this.Value };
        }

Do the same for the WinningBid object, but for this more complex type, add a new static factory method that enables a WinningBid to be created from a snapshot, as shown in Listing 21-86.

LISTING 21-86: Adding a New Method to the Winning Bid Class


namespace DDDPPP.Chap21.EFExample.Application.Model.Auction
{
    public class WinningBid : ValueObject<WinningBid>
    {
        private WinningBid() { }

        public WinningBid(Guid bidder, Money maximumBid, Money bid,
                          DateTime timeOfBid)
        {
            if (bidder == Guid.Empty)
                throw new ArgumentNullException("Bidder cannot be null");

            if (maximumBid == null)
                throw new ArgumentNullException("MaximumBid cannot be null");

            if (timeOfBid == DateTime.MinValue)
                throw new ArgumentNullException("TimeOfBid must have a value");

            Bidder = bidder;
            MaximumBid = maximumBid;
            TimeOfBid = timeOfBid;
            CurrentAuctionPrice = new Price(bid);
        }

        // ....

        public WinningBidSnapshot GetSnapshot()
        {
            var snapshot = new WinningBidSnapshot();

            snapshot.BiddersId = this.Bidder;
            snapshot.BiddersMaximumBid = this.MaximumBid.GetSnapshot().Value;
            snapshot.CurrentPrice =
                  this.CurrentAuctionPrice.Amount.GetSnapshot().Value;
            snapshot.TimeOfBid = this.TimeOfBid;

            return snapshot;
        }

        public static WinningBid CreateFrom(WinningBidSnapshot bidSnapshot)
        {
            return new WinningBid(bidSnapshot.BiddersId,
                                  new Money(bidSnapshot.BiddersMaximumBid),
                                  new Money(bidSnapshot.CurrentPrice),
                                  bidSnapshot.TimeOfBid);
        }

Finally, update the Auction class by adding the static factory class to hydrate an auction from a snapshot and the method to obtain a snapshot, as shown in Listing 21-87.

LISTING 21-87: Updating the Auction Class


namespace DDDPPP.Chap21.EFExample.Application.Model.Auction
{
    public class Auction : Entity<Guid>
    {
        public Auction(Guid id, Money startingPrice, DateTime endsAt)
        {

        if (id == Guid.Empty)
            throw new ArgumentNullException("Auction Id cannot be null");

        if (startingPrice == null)
            throw new ArgumentNullException("Starting Price cannot be null");

        if (endsAt == DateTime.MinValue)
            throw new ArgumentNullException("EndsAt must have a value");

            Id = id;
            StartingPrice = startingPrice;
            EndsAt = endsAt;
        }

        private Auction(AuctionSnapshot snapshot)
        {
            this.Id = snapshot.Id;
            this.StartingPrice = new Money(snapshot.StartingPrice);
            this.EndsAt = snapshot.EndsAt;
            this.Version = snapshot.Version;

            if (snapshot.WinningBid != null)
                WinningBid = WinningBid.CreateFrom(snapshot.WinningBid);
        }

        public static Auction CreateFrom(AuctionSnapshot snapshot)
        {
            return new Auction(snapshot);
        }

        private Money StartingPrice { get; set; }
        private WinningBid CurrentWinningBid { get; set; }
        private DateTime EndsAt { get; set; }

        public AuctionSnapshot GetSnapshot()
        {
            var snapshot = new AuctionSnapshot();
            snapshot.Id = this.Id;
            snapshot.StartingPrice = this.StartingPrice.GetSnapshot().Value;
            snapshot.EndsAt = this.EndsAt;
            snapshot.Version = this.Version;

            if (HasACurrentBid())
                snapshot.WinningBid = WinningBid.GetSnapshot();

            return snapshot;
        }

        private bool HasACurrentBid()
        {
            return WinningBid != null;
        }

        // ....

You also need to add the BidHistory object, as you did in the RavenDB example. Listing 21-88 shows an example.

LISTING 21-88: The Bid History Class


using System;
using System.Collections.Generic;
using System.Linq;

namespace DDDPPP.Chap21.EFExample.Application.Model.BidHistory
{
    public class BidHistory
    {
        private IEnumerable<Bid> _bids;

        public BidHistory(IEnumerable<Bid> bids)
        {
            if (bids == null)
              throw new ArgumentNullException("Bids cannot be null");

            _bids = bids;
        }

        public IEnumerable<Bid> ShowAllBids()
        {
            var bids = _bids.OrderByDescending(x => x.AmountBid)
                                              .ThenBy(x => x.TimeOfBid);

            return bids;
        }
    }
}

To retrieve the BidHistory object, you need to amend the IBidHistoryRepository, as shown in Listing 21-89.

LISTING 21-89: The Bid History Repository Interface


using System;

namespace DDDPPP.Chap21.EFExample.Application.Model.BidHistory
{
    public interface IBidHistoryRepository
    {
        int NoOfBidsFor(Guid autionId);
        void Add(Bid bid);
        BidHistory FindBy(Guid auctionId);
    }
}

Because you can’t track changes implicitly with your domain objects, you need to explicitly save them, which means you must add a save method to the IAuctionRepository, as shown in Listing 21-90.

LISTING 21-90: The Auction Repository Interface


using System;

namespace DDDPPP.Chap21.EFExample.Application.Model.Auction
{
    public interface IAuctionRepository
    {
        void Add(Auction auction);
        void Save(Auction auction);
        Auction FindBy(Guid Id);
    }
}

Entity Framework Repository Implementation

Create a new folder within the Infrastructure folder named DataModel. Here you stall the data model objects that map to your database tables and rows. The first object to create represents a row within the Auction table, as shown in Listing 21-91.

LISTING 21-91: The Auction Data Transfer Object


using System;
using System.Collections.Generic;

namespace DDDPPP.Chap21.EFExample.Application.Infrastructure.DataModel
{
    public partial class AuctionDTO
    {
        public System.Guid Id { get; set; }
        public decimal StartingPrice { get; set; }
        public DateTime AuctionEnds { get; set; }

        public Nullable<System.Guid> BidderMemberId { get; set; }
        public System.DateTime? TimeOfBid { get; set; }
        public Nullable<decimal> MaximumBid { get; set; }
        public Nullable<decimal> CurrentPrice { get; set; }

        public int Version { get; set; }
    }
}

The second data object, Listing 21-92, represents a row within the BidHistory table.

LISTING 21-92: The Bid Data Transfers Object


using System;
using System.Collections.Generic;

namespace DDDPPP.Chap21.EFExample.Application.Infrastructure.DataModel
{
    public partial class BidDTO
    {
        public System.Guid Id { get; set; }
        public System.Guid AuctionId { get; set; }
        public System.Guid BidderId { get; set; }
        public decimal Bid { get; set; }
        public System.DateTime TimeOfBid { get; set; }
    }
}

You will use Entity Framework’s code-first mapping to map the data model to the database. Add a new folder to the Infrastructure folder named Mapping. The AuctionMap class, Listing 21-93, maps the AuctionDTO to the Auctions database table.

LISTING 21-93: The Auction Map Class


using System.ComponentModel.DataAnnotations.Schema;
using System.Data.Entity.ModelConfiguration;
using DDDPPP.Chap21.EFExample.Application.Infrastructure.DataModel;

namespace DDDPPP.Chap21.EFExample.Application.Infrastructure.Mapping
{
    public class AuctionMap : EntityTypeConfiguration<AuctionDTO>
    {
        public AuctionMap()
        {
            this.HasKey(t => t.Id);

            this.ToTable("Auctions");
            this.Property(t => t.Id).HasColumnName("Id");
            this.Property(t => t.StartingPrice).HasColumnName("StartingPrice");
            this.Property(t =>
                            t.BidderMemberId).HasColumnName("BidderMemberId");
            this.Property(t => t.TimeOfBid).HasColumnName("TimeOfBid");
            this.Property(t => t.MaximumBid).HasColumnName("MaximumBid");
            this.Property(t => t.CurrentPrice).HasColumnName("CurrentPrice");
            this.Property(t => t.AuctionEnds).HasColumnName("AuctionEnds");
            this.Property(t =>
                  t.Version).HasColumnName("Version").IsConcurrencyToken();
        }
    }
}

Similarly, the BidMap, Listing 21-94, maps the BidDTO to the BidHistory table.

LISTING 21-94: The Bid Map Class


using System.ComponentModel.DataAnnotations.Schema;
using System.Data.Entity.ModelConfiguration;
using DDDPPP.Chap21.EFExample.Application.Infrastructure.DataModel;

namespace DDDPPP.Chap21.EFExample.Application.Infrastructure.Mapping
{
    public class BidMap : EntityTypeConfiguration<BidDTO>
    {
        public BidMap()
        {
            this.HasKey(t => t.Id);

            this.ToTable("BidHistory");
            this.Property(t => t.Id).HasColumnName("Id");
            this.Property(t => t.AuctionId).HasColumnName("AuctionId");
            this.Property(t => t.BidderId).HasColumnName("BidderId");
            this.Property(t => t.Bid).HasColumnName("Bid");
            this.Property(t => t.TimeOfBid).HasColumnName("TimeOfBid");
        }
    }
}

To talk to the database, you need a context, as shown in Listing 21-95. The Entity Framework DbContext is similar to NHibernate’s ISession and RavenDB’s IDocumentSession. It is effectively Entity Framework’s implementation of the unit-of-work pattern.

LISTING 21-95: Entity Framework’s Auction Database Context Class


using System.Data.Entity;
using System.Data.Entity.Infrastructure;
using DDDPPP.Chap21.EFExample.Application.Infrastructure.DataModel;
using DDDPPP.Chap21.EFExample.Application.Infrastructure.Mapping;

namespace DDDPPP.Chap21.EFExample.Application.Infrastructure
{
    public partial class AuctionDatabaseContext : DbContext
    {
        static AuctionDatabaseContext()
        {
            Database.SetInitializer<AuctionDatabaseContext>(null);
        }

        public AuctionDatabaseContext()
            : base("Name=AuctionDatabaseContext")
        {
        }

        public DbSet<AuctionDTO> Auctions { get; set; }
        public DbSet<BidDTO> Bids { get; set; }

        protected override void OnModelCreating(DbModelBuilder modelBuilder)
        {
            modelBuilder.Configurations.Add(new AuctionMap());
            modelBuilder.Configurations.Add(new BidMap());
        }

        public void Clear()
        {
            var context = ((IObjectContextAdapter)this).ObjectContext;

            var addedObjects = context
                             .ObjectStateManager
                             .GetObjectStateEntries(EntityState.Added);

            foreach (var objectStateEntry in addedObjects)
            {
                context.Detach(objectStateEntry.Entity);
            }

            var modifiedObjects = context
                             .ObjectStateManager
                             .GetObjectStateEntries(EntityState.Modified);

            foreach (var objectStateEntry in modifiedObjects)
            {
                context.Detach(objectStateEntry.Entity);
            }
        }
    }
}

The implementation of the repository is different from what you have seen in the NHibernate and RavenDB examples. Because you are unable to map the domain model directly to the data model, the repository needs to extract the snapshot and map that instead. The AuctionRepository implementation is shown in Listing 21-96.

LISTING 21-96: Entity Framework’s Auction Repository Implementation


using System;
using System.Collections.Generic;
using DDDPPP.Chap21.EFExample.Application.Model.Auction;
using DDDPPP.Chap21.EFExample.Application.Application;
using DDDPPP.Chap21.EFExample.Application.Infrastructure.DataModel;

namespace DDDPPP.Chap21.EFExample.Application.Infrastructure
{
    public class AuctionRepository : IAuctionRepository
    {
        private readonly AuctionDatabaseContext _auctionExampleContext;

        public AuctionRepository(AuctionDatabaseContext auctionExampleContext)
        {
            _auctionExampleContext = auctionExampleContext;
        }

        public void Add(Auction auction)
        {
            var auctionDTO = new AuctionDTO();

            Map(auctionDTO, auction.GetSnapshot());

           _auctionExampleContext.Auctions.Add(auctionDTO);
        }

        public void Save(Auction auction)
        {
            var auctionDTO = _auctionExampleContext.Auctions.Find(auction.Id);

            Map(auctionDTO, auction.GetSnapshot());
        }

        public Auction FindBy(Guid Id)
        {
            var auctionDTO = _auctionExampleContext.Auctions.Find(Id);
            var auctionSnapshot = new AuctionSnapshot();

            auctionSnapshot.Id = auctionDTO.Id;
            auctionSnapshot.EndsAt = auctionDTO.AuctionEnds;
            auctionSnapshot.StartingPrice = auctionDTO.StartingPrice;
            auctionSnapshot.Version = auctionDTO.Version;

            if (auctionDTO.BidderMemberId.HasValue)
            {
                var bidSnapshot = new WinningBidSnapshot();

                bidSnapshot.BiddersMaximumBid = auctionDTO.MaximumBid.Value;
                bidSnapshot.CurrentPrice = auctionDTO.CurrentPrice.Value;
                bidSnapshot.BiddersId = auctionDTO.BidderMemberId.Value;
                bidSnapshot.TimeOfBid = auctionDTO.TimeOfBid.Value;
                auctionSnapshot.WinningBid = bidSnapshot;
            }

            return Auction.CreateFrom(auctionSnapshot);
        }

        public void Map(AuctionDTO auctionDTO, AuctionSnapshot snapshot)
        {
            auctionDTO.Id = snapshot.Id;
            auctionDTO.StartingPrice = snapshot.StartingPrice;
            auctionDTO.AuctionEnds = snapshot.EndsAt;
            auctionDTO.Version = snapshot.Version;

            if (snapshot.WinningBid != null)
            {
                auctionDTO.BidderMemberId = snapshot.WinningBid.BiddersId;
                auctionDTO.CurrentPrice = snapshot.WinningBid.CurrentPrice;
                auctionDTO.MaximumBid = snapshot.WinningBid.BiddersMaximumBid;
                auctionDTO.TimeOfBid = snapshot.WinningBid.TimeOfBid;
            }
        }
    }
}

The BidHistoryRepository works along the same lines as what’s shown in Listing 21-97.

LISTING 21-97: The Bid History Repository


using System;
using System.Collections.Generic;
using System.Linq;
using DDDPPP.Chap21.EFExample.Application.Model.BidHistory;
using DDDPPP.Chap21.EFExample.Application.Model.Auction;
using DDDPPP.Chap21.EFExample.Application.Infrastructure.DataModel;

namespace DDDPPP.Chap21.EFExample.Application.Infrastructure
{
    public class BidHistoryRepository : IBidHistoryRepository
    {
        private readonly AuctionDatabaseContext _auctionExampleContext;

        public BidHistoryRepository(
                   AuctionDatabaseContext auctionExampleContext)
        {
            _auctionExampleContext = auctionExampleContext;
        }

        public int NoOfBidsFor(Guid autionId)
        {
            return _auctionExampleContext.Bids
                            .Count(x => x.AuctionId == autionId);
        }

        public void Add(Bid bid)
        {
            var bidDTO = new BidDTO();

            bidDTO.AuctionId = bid.AuctionId;
            bidDTO.Bid = bid.AmountBid.GetSnapshot().Value;
            bidDTO.BidderId = bid.Bidder;
            bidDTO.TimeOfBid = bid.TimeOfBid;

            bidDTO.Id = Guid.NewGuid();

            _auctionExampleContext.Bids.Add(bidDTO);
        }

        public BidHistory FindBy(Guid auctionId)
        {
            var bidDTOs = _auctionExampleContext.Bids.Where<BidDTO>(x =>
                                         x.AuctionId == auctionId).ToList();
            var bids = new List<Bid>();

            foreach (var bidDTO in bidDTOs)
            {
                bids.Add(new Bid(bidDTO.AuctionId, bidDTO.BidderId,
                                  new Money(bidDTO.Bid), bidDTO.TimeOfBid));
            }

            return new BidHistory(bids);
        }
    }
}

Application Service

There isn’t much difference in either of the application services from what you have seen up to now except for using the DbContext, which is Entity Framework’s unit of work implementation. The only thing of note is to say that Entity Framework implicitly wraps the call to SaveChanges in a transaction so you don’t need to. You can see these changes in Listing 21-98.

LISTING 21-98: The Create Auction Application Service


using System;
using System.Collections.Generic;
using System.Linq;
using DDDPPP.Chap21.EFExample.Application.Model.Auction;
using DDDPPP.Chap21.EFExample.Application.Model.BidHistory;
using DDDPPP.Chap21.EFExample.Application.Infrastructure;

namespace DDDPPP.Chap21.EFExample.Application.Application.BusinessUseCases
{
    public class CreateAuction
    {
        private IAuctionRepository _auctions;
        private AuctionDatabaseContext _unitOfWork;

        public CreateAuction(IAuctionRepository auctions,
                             AuctionDatabaseContext unitOfWork)
        {
            _auctions = auctions;
            _unitOfWork = unitOfWork;
        }

        public Guid Create(NewAuctionRequest command)
        {
            var auctionId = Guid.NewGuid();
            var startingPrice = new Money(command.StartingPrice);

            _auctions.Add(new Auction(auctionId, startingPrice,
                                                command.EndsAt));

            _unitOfWork.SaveChanges();

            return auctionId;
        }
    }
}

In the BidOnAuction application service, Listing 21-99, you need to explicitly call the Save method on the repository. The only other difference is that the exception type that is thrown when there is a concurrency issue is different from both the NHibernate and RavenDB examples.

LISTING 21-99: The Bid On Auction Application Service


using System;
using System.Collections.Generic;
using DDDPPP.Chap21.EFExample.Application.Model.Auction;
using DDDPPP.Chap21.EFExample.Application.Model.BidHistory;
using DDDPPP.Chap21.EFExample.Application.Infrastructure;
using System.Data.Entity.Infrastructure;

namespace DDDPPP.Chap21.EFExample.Application.Application.BusinessUseCases
{
    public class BidOnAuction
    {
        private IAuctionRepository _auctions;
        private IBidHistoryRepository _bidHistory;
        private AuctionDatabaseContext _unitOfWork;
        private IClock _clock;

        public BidOnAuction(IAuctionRepository auctions,
                            IBidHistoryRepository bidHistory,
                            AuctionDatabaseContext unitOfWork, IClock clock)
        {
            _auctions = auctions;
            _bidHistory = bidHistory;
            _unitOfWork = unitOfWork;
            _clock = clock;
        }

        public void Bid(Guid auctionId, Guid memberId, decimal amount)
        {
            try
            {
                using (DomainEvents.Register(OutBid()))
                using (DomainEvents.Register(BidPlaced()))
                {
                    var auction = _auctions.FindBy(auctionId);

                    var bidAmount = new Money(amount);

                    auction.PlaceBidFor(new Offer(memberId, bidAmount,
                                           _clock.Time()), _clock.Time());

                    _auctions.Save(auction);
                }

                _unitOfWork.SaveChanges();
            }
            catch (DbUpdateConcurrencyException ex)
            {
                _unitOfWork.Clear();

                Bid(auctionId, memberId, amount);
            }
        }

        private Action<BidPlaced> BidPlaced()
        {
            return (BidPlaced e) =>
            {
                var bidEvent = new Bid(e.AuctionId, e.Bidder,
                                       e.AmountBid, e.TimeOfBid);

                _bidHistory.Add(bidEvent);
            };
        }

        private Action<OutBid> OutBid()
        {
            return (OutBid e) =>
            {
                // E-mail customer to say that he has been outbid
            };
        }
    }
}

Querying

To implement the queries, you can utilize the snapshots to populate the view models, as shown in Listing 21-100 and Listing 21-101 for the AuctionStatusQuery and the BidHistoryQuery.

LISTING 21-100: The Auction Status Query


using System;
using System.Collections.Generic;
using DDDPPP.Chap21.EFExample.Application.Model.Auction;
using DDDPPP.Chap21.EFExample.Application.Model.BidHistory;
using DDDPPP.Chap21.EFExample.Application.Infrastructure;

namespace DDDPPP.Chap21.EFExample.Application.Application.Queries
{
    public class AuctionStatusQuery
    {
        private readonly IAuctionRepository _auctions;
        private readonly IBidHistoryRepository _bidHistory;
        private readonly IClock _clock;

        public AuctionStatusQuery(IAuctionRepository auctions,
                                  IBidHistoryRepository bidHistory,
                                  IClock clock)
        {
            _auctions = auctions;
            _bidHistory = bidHistory;
            _clock = clock;
        }

        public AuctionStatus AuctionStatus(Guid auctionId)
        {
            var auction = _auctions.FindBy(auctionId);

            var snapshot = auction.GetSnapshot();

            return ConvertToStatus(snapshot);
        }

        public AuctionStatus ConvertToStatus(AuctionSnapshot snapshot)
        {
            var status = new AuctionStatus();

            status.AuctionEnds = snapshot.EndsAt;
            status.Id = snapshot.Id;
            status.TimeRemaining = TimeRemaining(snapshot.EndsAt);

            if (snapShot.WinningBid != null)
            {
                status.NumberOfBids = _bidHistory.NoOfBidsFor(snapshot.Id);
                status.WinningBidderId = snapshot.WinningBid.BiddersId;
                status.CurrentPrice = snapshot.WinningBid.CurrentPrice;
            }

            return status;
        }

        public TimeSpan TimeRemaining(DateTime AuctionEnds)
        {
            if (_clock.Time() < AuctionEnds)
                return AuctionEnds.Subtract(_clock.Time());
            else
                return new TimeSpan();
        }
    }
}

LISTING 21-101: The Bid Histroy Query


using System;
using System.Collections.Generic;
using DDDPPP.Chap21.EFExample.Application.Infrastructure;
using DDDPPP.Chap21.EFExample.Application.Model.BidHistory;

namespace DDDPPP.Chap21.EFExample.Application.Application.Queries
{
    public class BidHistoryQuery
    {
        private readonly IBidHistory _bidHistory;

        public BidHistoryQuery(IBidHistory bidHistory)
        {
            _bidHistory = bidHistory;
        }

        public IEnumerable<BidInformation> BidHistoryFor(Guid auctionId)
        {
            var bidHistory = _bidHistory.FindBy(auctionId);

            return Convert(bidHistory.ShowAllBids());
        }

        public IEnumerable<BidInformation> Convert(IEnumerable<BidEvent> bids)
        {
            var bidInfo = new List<BidInformation>();

            foreach (var bid in bids)
            {
                bidInfo.Add(new BidInformation() { Bidder = bid.Bidder,
                               AmountBid = bid.AmountBid.GetSnapshot().Value,
                               TimeOfBid = bid.TimeOfBid });
            }

            return bidInfo;
        }
    }
}

Configuration

Again, you will be using StructureMap to wire up your dependencies, so install it as before from NuGet and create a bootstrapper class with Listing 21-102.

LISTING 21-102: The StructureMap Bootstrapper Class


using System;
using StructureMap;
using DDDPPP.Chap21.EFExample.Application.Infrastructure;
using DDDPPP.Chap21.EFExample.Application.Model.Auction;
using DDDPPP.Chap21.EFExample.Application.Model.BidHistory;

namespace DDDPPP.Chap21.EFExample.Application
{
    public static class Bootstrapper
    {
        public static void Startup()
        {
            ObjectFactory.Initialize(config =>
            {
                config.For<IAuctionRepository>().Use<AuctionRepository>();
                config.For<IBidHistoryRepository>()
                                                .Use<BidHistoryRepository>();
                config.For<IClock>().Use<SystemClock>();
            });
        }
    }
}

Lastly, add the XML snippet in Listing 21-103 to the app.config within the Presentation console application.

LISTING 21-103: The Entity Framework Configuration


<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <configSections>
    <!–– For more information on Entity Framework configuration, visit
                           http://go.microsoft.com/fwlink/?LinkID=237468 ––>
    <section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection,
                        EntityFramework, Version=6.0.0.0, Culture=neutral,
                 PublicKeyToken=b77a5c561934e089" requirePermission="false" />
  <!–– For more information on Entity Framework configuration, visit
             http://go.microsoft.com/fwlink/?LinkID=237468 ––></configSections>
  <connectionStrings>
    <add name="AuctionDatabaseContext" connectionString="Data
       Source=.sqlexpress;Initial Catalog=AuctionExample;Integrated
                        Security=True;MultipleActiveResultSets=True"
                                 providerName="System.Data.SqlClient" />
  </connectionStrings>
  <entityFramework>
    <defaultConnectionFactory
                type="System.Data.Entity.Infrastructure.SqlConnectionFactory,
                                   EntityFramework" />
    <providers>
      <provider invariantName="System.Data.SqlClient"
               type="System.Data.Entity.SqlServer.SqlProviderServices,
                                               EntityFramework.SqlServer" />
    </providers>
  </entityFramework>
    <startup>
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
    </startup>
</configuration>

If you run the console application, you will see the same results as in the previous NHibernate and RavenDB examples.

Micro ORM Example

Dapper is a micro ORM, meaning that it helps you map database rows to objects but (by design) does little else. In this example, you need to build your own unit of work implementation and concurrency checks.

Solution Setup

To get started, create a new blank Visual Studio solution named DDDPPP.Chap21.MicroORM and add to this a class library named DDDPPP.Chap21.MicroORM.Application and a console application named DDDPPP.Chap21.MicroORM.Presentation. Within the Presentation project, add a reference to the application. You can delete the Class1.cs that is automatically created because you won't be needing it. Use NuGet to install the Dapper client libraries, as shown in Figure 21.20.

The model is the same as the model you created for the Entity Framework example. It also has the database schema that you used in both the NHibernate and Entity Framework examples. Build out the application in the same manner as you did for the Entity Framework, but exclude the following files:

BusinessUseCases/BidOnAuction.cs
BusinessUseCases/CreateAuction.cs
Infrastructure/Mapping
Infrastructure/AuctionDatabaseContext.cs
Infrastructure/AuctionRepository.cs
Infrastructure/BidHistoryRepository.cs
Bootstrapper.cs

You should now be left with a solution that resembles Figure 21.21.

Infrastructure

In this example we’re using a micro ORM. Micro orms tend to focus on simplicity and performance, as such they have less features than their fully automated cousins Entity Framework and NHibernate. Consequently we will need to implement the unit of work pattern ourselves. The unit of work structure in this example is based on the framework that Tim McCarthy uses in his book .NET Domain-Driven Design with C#: Problem-Design-Solution.

The IAggregateDataModel interface, Listing 21-104, is actually a pattern in itself called the marker interface pattern. The interface acts as metadata for a class, and methods that interact with instances of that class test for the existence of the interface before carrying out their work. You will see this pattern used later in this chapter when you build a repository layer that only persists business objects that implement the IAggregateDataModel interface.

LISTING 21-104: The IAggregateDataModel Interface


using System;

namespace DDDPPP.Chap21.MicroORM.Application.Infrastructure
{
    public interface IAggregateDataModel
    {
    }
}

The unit of work implementation uses the IAggregateDataModel interface to reference any business entity that is partaking in an atomic transaction. Add another interface to the Infrastructure project named IUnitOfWorkRepository, Listing 21-105, with the contract listing that follows.

LISTING 21-105: The IUnitofWorkRepository Interface


using System;

namespace DDDPPP.Chap21.MicroORM.Application.Infrastructure
{
    public interface IUnitOfWorkRepository
    {
        void PersistCreationOf(IAggregateDataModel entity);
        void PersistUpdateOf(IAggregateDataModel entity);
    }
}

The IUnitOfWorkRepository is a second interface that all repositories are required to implement if they intend to be used in a unit of work. You could have added this contract definition to the model Repository interface that you will add later, but the interfaces are addressing two different types of concerns. This is the definition of the Interface Segregation Principle. You are not going to be deleting anything in your application, so there is no need to add that method.

Finally, add a third interface to the Infrastructure project named IUnitOfWork, the definition of which you can find in Listing 21-106.

LISTING 21-106: The IUnitOfWork Interface


using System;

namespace DDDPPP.Chap21.MicroORM.Application.Infrastructure
{
    public interface IUnitOfWork
    {
        void RegisterAmended(IAggregateDataModel entity,
                      IUnitOfWorkRepository unitofWorkRepository);
        void RegisterNew(IAggregateDataModel entity,
                      IUnitOfWorkRepository unitofWorkRepository);
        void Commit();
        void Clear();
    }
}

The IUnitOfWork interface requires the IUnitOfWorkRepository when registering an amend/ addition/deletion so that, on commitment, the unit of work can delegate the work of the actual persistence method to the appropriate concrete implementation. The logic behind the IUnitOfWork methods will become a lot clearer when you look at a default implementation of the IUnitOfWork interface and create the repositories.

The last class to create is the ConcurrencyException, Listing 21-107, which is thrown if the auction is updated between retrieving it, placing a bid, and persisting it.

LISTING 21-107: The Concurrency Exception Class


using System;

namespace DDDPPP.Chap21.MicroORM.Application.Infrastructure
{
    public class ConcurrencyException : ApplicationException
    {
    }
}

Application Service

Both of the application services should be familiar to you by now. Listing 21-108 and Listing 21-109 change because of your implementation of the unit of work and because of your concurrency exception type.

LISTING 21-108: The Create Auction Application Service


using System;
using DDDPPP.Chap21.MicroORM.Application.Model.Auction;
using DDDPPP.Chap21.MicroORM.Application.Infrastructure;

namespace DDDPPP.Chap21.MicroORM.Application.Application.BusinessUseCases
{
    public class CreateAuction
    {
        private IAuctionRepository _auctionRepository;
        private IUnitOfWork _unitOfWork;

        public CreateAuction(IAuctionRepository auctionRepository,
                             IUnitOfWork unitOfWork)
        {
            _auctionRepository = auctionRepository;
            _unitOfWork = unitOfWork;
        }

        public Guid Create(NewAuctionRequest command)
        {
            var auctionId = Guid.NewGuid();
            var startingPrice = new Money(command.StartingPrice);

            _auctionRepository.Add(new Auction(auctionId,
                                    startingPrice, command.EndsAt));

            _unitOfWork.Commit();

            return auctionId;
        }
    }
}

LISTING 21-109: The Bid On Auction Application Service


using System;
using DDDPPP.Chap21.MicroORM.Application.Model.Auction;
using DDDPPP.Chap21.MicroORM.Application.Model.BidHistory;
using DDDPPP.Chap21.MicroORM.Application.Infrastructure;

namespace DDDPPP.Chap21.MicroORM.Application.Application.BusinessUseCases
{
    public class BidOnAuction
    {
        private IAuctionRepository _auctionRepository;
        private IBidHistoryRepository _bidHistoryRepository;
        private IUnitOfWork _unitOfWork;
        private IClock _clock;

        public BidOnAuction(IAuctionRepository auctionRepository,
                            IBidHistoryRepository bidHistoryRepository,
                            IUnitOfWork unitOfWork, IClock clock)
        {
            _auctionRepository = auctionRepository;
            _bidHistoryRepository = bidHistoryRepository;
            _unitOfWork = unitOfWork;
            _clock = clock;
        }

        public void Bid(Guid auctionId, Guid memberId, decimal amount)
        {
            try
            {
                using (DomainEvents.Register(OutBid()))
                using (DomainEvents.Register(BidPlaced()))
                {
                    var auction = _auctionRepository.FindBy(auctionId);

                    var bidAmount = new Money(amount);

                    auction.PlaceBidFor(new Offer(memberId, bidAmount,
                                       _clock.Time()), _clock.Time());

                    _auctionRepository.Save(auction);
                }

                _unitOfWork.Commit();
            }
            catch (ConcurrencyException ex)
            {
                _unitOfWork.Clear();

                Bid(auctionId, memberId, amount);
            }
        }

        private Action<BidPlaced> BidPlaced()
        {
            return (BidPlaced e) =>
            {
                var bidEvent = new Bid(e.AuctionId, e.Bidder, e.AmountBid,
                                       e.TimeOfBid);

                _bidHistoryRepository.Add(bidEvent);
            };
        }

        private Action<OutBid> OutBid()
        {
            return (OutBid e) =>
            {
                // E-mail customer to say that he has been outbid
            };
        }
    }
}

ADO.NET Repository Implementation

You need to make the AuctionDTO, Listing 21-110, and BidDTO, Listing 21-111, implement the IAggregateDataModel interface because these two classes are persisted using the unit of work implementation.

LISTING 21-110: Updating the AuctionDTO to Implementing the IAggregateDataModel


namespace DDDPPP.Chap21.MicroORM.Application.Infrastructure.DataModel
{
    public partial class AuctionDTO : IAggregateDataModel
    {
        // ......
    }
}

LISTING 21-111: Updating the BidDTO to Implementing the IAggregateDataModel


namespace DDDPPP.Chap21.MicroORM.Application.Infrastructure.DataModel
{
    public partial class BidDTO : IAggregateDataModel
    {
        // ......
    }
}

Both AuctionRepository and BidHistoryRepository, shown in Listing 21-112 and Listing 21-113, implement the domain model repository contracts IAuctionRepository and IBidHistoryRepository, as well as the IUnitOfWorkRepository interface. The implementations of both repository methods simply delegate work to the unit of work, passing the entity to be persisted along with a reference to the repository, which of course implements the IUnitOfWorkRepository. As seen previously when the unit of work’s Commit method is called, the unit of work refers to the repository’s implementation of the IUnitOfWorkRepository contract to perform the real persistence requirements. This is the same behavior as you saw in the enterprise-level frameworks. Because the repositories need to obtain a connection string from the app.config file, you need to add a reference to the Systems.Configuration assembly, as shown in Figure 21.22.

LISTING 21-112: The Auction Repository Implementation


using System;
using System.Collections.Generic;
using System.Linq;
using DDDPPP.Chap21.MicroORM.Application.Model.Auction;
using DDDPPP.Chap21.MicroORM.Application.Application;
using DDDPPP.Chap21.MicroORM.Application.Infrastructure.DataModel;
using System.Data.SqlClient;
using Dapper;

namespace DDDPPP.Chap21.MicroORM.Application.Infrastructure
{
    public class AuctionRepository : IAuctionRepository, IUnitOfWorkRepository
    {
        private IUnitOfWork _unitOfWork;

        public AuctionRepository(IUnitOfWork unitOfWork)
        {
            _unitOfWork = unitOfWork;
        }

        public void Add(Auction auction)
        {
            var snapshot = auction.GetSnapshot();
            var auctionDTO = new AuctionDTO();

            Map(auctionDTO, snapshot);

            _unitOfWork.RegisterNew(auctionDTO, this);
        }

        public void Save(Auction auction)
        {
            var snapshot = auction.GetSnapshot();
            var auctionDTO = new AuctionDTO();


            Map(auctionDTO, snapshot);

            _unitOfWork.RegisterAmended(auctionDTO, this);
        }

        public Auction FindBy(Guid Id)
        {
            AuctionDTO auctionDTO;

            using (var connection = new
                    SqlConnection(System.Configuration.ConfigurationManager
                          .ConnectionStrings["AuctionDB"].ConnectionString))
            {
                auctionDTO = connection.Query<AuctionDTO>("Select * From" +
                            "Auctions Where Id = CAST(@Id AS uniqueidentifier)"
                               , new { Id = Id }).FirstOrDefault();
            }

            var auctionSnapshot = new AuctionSnapshot();

            auctionSnapshot.Id = auctionDTO.Id;
            auctionSnapshot.EndsAt = auctionDTO.AuctionEnds;
            auctionSnapshot.StartingPrice = auctionDTO.StartingPrice;
            auctionSnapshot.Version = auctionDTO.Version;

            if (auctionDTO.BidderMemberId.HasValue)
            {
                var bidSnapshot = new WinningBidSnapshot();

                bidSnapshot.BiddersMaximumBid = auctionDTO.MaximumBid.Value;
                bidSnapshot.CurrentPrice = auctionDTO.CurrentPrice.Value;
                bidSnapshot.BiddersId = auctionDTO.BidderMemberId.Value;
                bidSnapshot.TimeOfBid = auctionDTO.TimeOfBid.Value;
                auctionSnapshot.WinningBid = bidSnapshot;
            }

            return Auction.CreateFrom(auctionSnapshot);
        }

        public void PersistCreationOf(IAggregateDataModel entity)
        {
            var auctionDTO = (AuctionDTO)entity;

            using (var connection = new
                 SqlConnection(System.Configuration.ConfigurationManager
               .ConnectionStrings["AuctionDB"].ConnectionString))
            {
                var recordsAdded = connection.Execute(@"
                    INSERT INTO [AuctionExample].[dbo].[Auctions]
                           ([Id]
                           ,[StartingPrice]
                           ,[BidderMemberId]
                           ,[TimeOfBid]
                           ,[MaximumBid]
                           ,[CurrentPrice]
                           ,[AuctionEnds]
                           ,[Version])
                     VALUES
                           (@Id, @StartingPrice, @BidderMemberId, @TimeOfBid,
                          @MaximumBid, @CurrentPrice, @AuctionEnds, @Version)"
                    , new { Id = auctionDTO.Id, StartingPrice =
                               auctionDTO.StartingPrice,
                               BidderMemberId = auctionDTO.BidderMemberId,
                            TimeOfBid = auctionDTO.TimeOfBid,
                            MaximumBid = auctionDTO.MaximumBid,
                           CurrentPrice = auctionDTO.CurrentPrice,
                            AuctionEnds = auctionDTO.AuctionEnds,
                            Version = auctionDTO.Version });
            }
        }

        public void PersistUpdateOf(IAggregateDataModel  entity)
        {
            var auctionDTO = (AuctionDTO)entity;

            using (var connection = new
                        SqlConnection(System.Configuration.ConfigurationManager
                       .ConnectionStrings["AuctionDB"].ConnectionString))
            {
                var recordsUpdated = connection.Execute(@"
                    UPDATE
                        [AuctionExample].[dbo].[Auctions]
                    SET
                        [Id] = @Id
                       ,[StartingPrice] = @StartingPrice
                       ,[BidderMemberId] = @BidderMemberId
                       ,[TimeOfBid] = @TimeOfBid
                       ,[MaximumBid] = @MaximumBid
                       ,[CurrentPrice] = @CurrentPrice
                       ,[AuctionEnds] = @AuctionEnds
                       ,[Version] = @Version
                    WHERE
                        Id = @Id AND Version = @PreviousVersion"
                    , new
                    {
                        Id = auctionDTO.Id,
                        StartingPrice = auctionDTO.StartingPrice,
                        BidderMemberId = auctionDTO.BidderMemberId,
                        TimeOfBid = auctionDTO.TimeOfBid,
                        MaximumBid = auctionDTO.MaximumBid,
                        CurrentPrice = auctionDTO.CurrentPrice,
                        AuctionEnds = auctionDTO.AuctionEnds,
                        Version = auctionDTO.Version + 1,
                        PreviousVersion = auctionDTO.Version
                    });

                if (!recordsUpdated.Equals(1))
                {
                    throw new ConcurrencyException();
                }
            }
        }

        public void Map(AuctionDTO auctionDTO, AuctionSnapshot snapshot)
        {
            auctionDTO.Id = snapshot.Id;
            auctionDTO.StartingPrice = snapshot.StartingPrice;
            auctionDTO.AuctionEnds = snapshot.EndsAt;
            auctionDTO.Version = snapshot.Version;

            if (snapshot.WinningBid != null)
            {
                auctionDTO.BidderMemberId = snapshot.WinningBid.BiddersId;
                auctionDTO.CurrentPrice = snapshot.WinningBid.CurrentPrice;
                auctionDTO.MaximumBid = snapshot.WinningBid.BiddersMaximumBid;
                auctionDTO.TimeOfBid = snapshot.WinningBid.TimeOfBid;
            }
        }
    }
}

LISTING 21-113: The Bid History Repository Implementation


using System;
using System.Collections.Generic;
using System.Linq;
using DDDPPP.Chap21.MicroORM.Application.Model.BidHistory;
using DDDPPP.Chap21.MicroORM.Application.Model.Auction;
using DDDPPP.Chap21.MicroORM.Application.Infrastructure.DataModel;
using Dapper;
using System.Data.SqlClient;

namespace DDDPPP.Chap21.MicroORM.Application.Infrastructure
{
    public class BidHistoryRepository : IBidHistoryRepository,
                                        IUnitOfWorkRepository
    {
        private IUnitOfWork _unitOfWork;

        public BidHistoryRepository(IUnitOfWork unitOfWork)
        {
            _unitOfWork = unitOfWork;
        }

        public int NoOfBidsFor(Guid auctionId)
        {
            int count;

            using (var connection = new
               SqlConnection(System.Configuration.ConfigurationManager
              .ConnectionStrings["AuctionDB"].ConnectionString))
            {
                var count1 = connection.Query<int>(
            "Select Count(*) From BidHistory Where AuctionId = @Id",
                  new { Id = auctionId }).FirstOrDefault();

                count = count1 != null ? count1 : 1;
            }

            return count;
        }

        public void Add(Bid bid)
        {
            var bidHistoryDTO = new BidDTO();

            bidHistoryDTO.AuctionId = bid.AuctionId;
            bidHistoryDTO.Bid = bid.AmountBid.GetSnapshot().Value;
            bidHistoryDTO.BidderId = bid.Bidder;
            bidHistoryDTO.TimeOfBid = bid.TimeOfBid;

            bidHistoryDTO.Id = Guid.NewGuid();

            _unitOfWork.RegisterNew(bidHistoryDTO, this);
        }

        public BidHistory FindBy(Guid auctionId)
        {
            IEnumerable<BidDTO> bidDTOs;

            using (var connection = new
                   SqlConnection(System.Configuration.ConfigurationManager
                .ConnectionStrings["AuctionDB"].ConnectionString))
            {
                bidDTOs = connection.Query<BidDTO>(
                    "Select * From BidHistory Where AuctionId = @Id",
                      new { Id = auctionId });
            }

            var bids = new List<Bid>();

            foreach (var bid in bidDTOs)
            {
                bids.Add(new Bid(bid.AuctionId, bid.BidderId,
                         new Money(bid.Bid), bid.TimeOfBid));
            }

            return new BidHistory(bids);
        }

        public void PersistCreationOf(IAggregateDataModel entity)
        {
            var bidHistoryDTO = (BidDTO)entity;

            using (var connection = new
              SqlConnection(System.Configuration.ConfigurationManager
              .ConnectionStrings["AuctionDB"].ConnectionString))
            {
                connection.Execute(@"
                    INSERT INTO [dbo].[BidHistory]
                           ([AuctionId]
                           ,[BidderId]
                           ,[Bid]
                           ,[TimeOfBid]
                           ,[Id])
                     VALUES
                           (@AuctionId
                           ,@BidderId
                           ,@Bid
                           ,@TimeOfBid
                           ,@Id)"
                    , new
                    {
                        Id = bidHistoryDTO.Id,
                        BidderId = bidHistoryDTO.BidderId,
                        Bid = bidHistoryDTO.Bid,
                        TimeOfBid = bidHistoryDTO.TimeOfBid,
                        AuctionId = bidHistoryDTO.AuctionId
                    });
            }
        }

        public void PersistUpdateOf(IAggregateDataModel entity)
        {
            throw new NotImplementedException();
        }
    }
}

To complete the repository implementation, you need to implement the unit-of-work interface. Add a new class to the Infrastructure folder named UnitOfWork, and use Listing 21-113 to update the newly created class.

LISTING 21-114: The Unit-of-Work Implementation


using System;
using System.Collections.Generic;
using System.Transactions;

namespace DDDPPP.Chap21.MicroORM.Application.Infrastructure
{
    public class UnitOfWork : IUnitOfWork
    {
        private Dictionary<IAggregateDataModel, IUnitOfWorkRepository>
                                  addedEntities;
        private Dictionary<IAggregateDataModel, IUnitOfWorkRepository>
                                  changedEntities;

        public UnitOfWork()
        {
            addedEntities = new Dictionary<IAggregateDataModel,
                                             IUnitOfWorkRepository>();
            changedEntities = new Dictionary<IAggregateDataModel,
                                             IUnitOfWorkRepository>();
        }

        public void RegisterAmended(IAggregateDataModel entity,
                            IUnitOfWorkRepository unitofWorkRepository)
        {
            if (!changedEntities.ContainsKey(entity))
            {
                changedEntities.Add(entity, unitofWorkRepository);
            }
        }

        public void RegisterNew(IAggregateDataModel entity,
                        IUnitOfWorkRepository unitofWorkRepository)
        {
            if (!addedEntities.ContainsKey(entity))
            {
                addedEntities.Add(entity, unitofWorkRepository);
            };
        }

        public void Clear()
        {
            addedEntities.Clear();
            changedEntities.Clear();
        }

        public void Commit()
        {
            using (TransactionScope scope = new TransactionScope())
            {
                foreach (IAggregateDataModel entity in this.addedEntities.Keys)
                {
                    this.addedEntities[entity].PersistCreationOf(entity);
                }

                foreach (IAggregateDataModel entity in
                                        this.changedEntities.Keys)
                {
                    this.changedEntities[entity].PersistUpdateOf(entity);
                }

                scope.Complete();

                Clear();
            }
        }

    }
}

You are required to add a reference to System.Transactions so you can use the TransactionScope class, as shown in Figure 21.23, which ensures the persistence will commit in an atomic transaction.

The UnitOfWork class uses three dictionaries to track pending changes to business entities. The first dictionary corresponds to entities to be added to the datastore. The second dictionary tracks entities to be updated, and the third deals with entity removal. A matching IUnitOfWorkRepository is stored against the entity key in the dictionary and is used in the Commit method to call the repository, which contains the code to actually persist an entity. The Commit method loops through each dictionary and calls the appropriate IUnitOfWorkRepository method, passing a reference to the entity. The work in the Commit method is wrapped in a TransactionScope using a block; this ensures that no work is done until the TransactionScope Complete method is called. If an exception occurs while you are performing work within the IUnitOfWorkRepository, all work is rolled back, and the datastore is left in its original state.

Configuration

Again, you will wire up the dependencies of the application services using StructureMap, which you can install via NuGet just as you did with NHibernate and RavenDB. The code is shown in Listing 21-115.

LISTING 21-115: The Bootstrapper Class for Wiring Up Dependencies


using System;
using StructureMap;
using DDDPPP.Chap21.MicroORM.Application.Infrastructure;
using DDDPPP.Chap21.MicroORM.Application.Model.Auction;
using DDDPPP.Chap21.MicroORM.Application.Model.BidHistory;

namespace DDDPPP.Chap21.MicroORM.Application
{
    public static class Bootstrapper
    {
        public static void Startup()
        {
            ObjectFactory.Initialize(config =>
            {
                config.For<IAuctionRepository>().Use<AuctionRepository>();
                config.For<IBidHistoryRepository>()
                                    .Use<BidHistoryRepository>();
                config.For<IClock>().Use<SystemClock>();

                config.For<IUnitOfWork>()
                    .HybridHttpOrThreadLocalScoped()
                    .Use(x =>
                    {
                        var uow = new UnitOfWork();
                        return uow;
                    });
            });
        }
    }
}

To set the connection string to the database, update the App.Config within the presentation project to match the XML markup in Listing 21-116.

LISTING 21-116: The app.config File with Connection String Details


<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
  </startup>

  <connectionStrings>
    <add name="AuctionDB" connectionString="Data Source=.sqlexpress;Initial
Catalog=AuctionExample;Integrated Security=True;MultipleActiveResultSets=True"
providerName="System.Data.SqlClient" />
  </connectionStrings>
</configuration>

You can now run the program and see the same results, as in all the examples.

The Salient Points

The repository mediates between the domain model and the data model; it maps the domain model to a persistence store.
The repository pattern is a procedural boundary, keeping the domain model free of infrastructural concerns.
The repository is a contract, not a data access layer. It explicitly states what operations are available for each aggregate—that is, which you can modify and which you can remove.
The repository is for transactional behavior, not for ad hoc reporting. Using explicit query names provides more information.
A repository hides the mechanisms for querying the data model and supports the Tell, Don’t Ask principle.
An ORM framework is not a repository. The repository is an architectural pattern, whereas an ORM is a means to represent the data model as an object model. A repository can use an ORM to assist in mediating between the domain model and the data model
Your persistence framework affects the way your domain model is constructed. Be pragmatic, and don’t fight your framework in the quest for needless purity.
The repository is best used for bounded contexts with a rich domain model. For simpler bounded contexts without complex business logic, use the persistence framework directly.
When managing transactions, use a unit of work. The unit of work tracks which objects have been removed, added, or updated. The repository is responsible for the actual persistence, performed within a transaction coordinated by the unit of work.
A repository should be scoped to updating a single aggregate; it should not control a transaction. This should be the responsibility of a unit of work.

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

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

Table of Contents for Chapter 21: Repositories

Create new playlist

Sign In

Sign Up

Repositories

A Misunderstood Pattern

Is the Repository an Antipattern?

The Difference between a Domain Model and a Persistence Model

The Generic Repository

Aggregate Persistence Strategies

Using a Persistence Framework That Can Map the Domain Model to the Data Model without Compromise

Using a Persistence Framework That Cannot Map the Domain Model Directly without Compromise

Public Getters and Setters

Using the Memento Pattern

Event Streams

Be Pragmatic

A Repository Is an Explicit Contract

Transaction Management and Units of Work

To Save or Not To Save

Persistence Frameworks That Track Domain Object Changes

Having to Explicitly Save Changes to Aggregates

The Repository as an Anticorruption Layer

Other Responsibilities of a Repository

Entity ID Generation

Collection Summaries

Concurrency

Audit Trails

Repository Antipatterns

Antipatterns: Don’t Support Ad Hoc Queries

Antipatterns: Lazy Loading Is Design Smell

Antipatterns: Don’t Use Repositories for Reporting Needs

Repository Implementations

Persistence Framework Can Map Domain Model to Data Model without Compromise

NHibernate Example

Solution Setup

Creating the Model

Application Service

NHibernate Repository Implementation

Database Schema

Querying

Configuration

Presentation

RavenDB Example

Solution Setup

Altering the Model

Application Service

Querying

RavenDB Repository Implementation

Configuration

Persistence Framework Cannot Map Domain Model Directly without Compromise

Entity Framework Example

Solution Setup

Altering the Model

Entity Framework Repository Implementation

Table of Contents for
Chapter 21: Repositories