My previous post on Domain Events left some questions about how aggregate roots should be created unanswered. It would actually be more accurate to say how aggregate roots should *not* be created. It turns out that this is one of the less intuitive parts of domain-driven design and has been the source of many arguments on the matter. Let’s start with the wrong way:

   1:  using (ISession s = sf.OpenSession())

   2:  using (ITransaction tx = s.BeginTransaction())

   3:  {

   4:      Customer c = new Customer();

   5:      c.Name = "udi dahan";

   6:   

   7:      s.Save(c);

   8:      tx.Commit();

   9:  }

I understand that the code above is representative of how much code is written when using an object-relational mapper. Many would consider this code to follow DDD principles – that Customer is an aggregate root. Unfortunately – that is not the case. The code above is missing the real aggregate root.

There’s also the inevitable question of validation – if the customer object isn’t willing to accept a name with a space in it, should we throw an exception? That would prevent an invalid entity from being saved, which is good. On the other hand, exceptions should be reserved for truly exceptional occurrences. But if we don’t use exceptions, using Domain Events instead, how do we prevent the invalid entity from being saved?

All of these issues are handled auto-magically once we have a true aggregate root.

Always Get An Entity

Let’s start with the technical guidance – always get an entity. At least one. Also, don’t add any objects to the session or unit of work explicitly – rather, have some other already persistent domain entity create the new entity and add it to a collection property.

Looking at the code above, we see that we’re not following the technical guidance.

But the question is, which entity could we possibly get from the database in this case? All we’re doing is adding a customer.

And that’s exactly where the technical guidance leads us to the business analysis that was missing in this scenario…

Business Analysis

Customers don’t just appear out of thin air.

Blindingly obvious – isn’t it.

So why would we technically model our system as if they did? My guess is that we never really thought about it – it wasn’t our job. So here’s the breaking news – if we want to successfully apply DDD we do need to think about it, it is our job.

Going back to the critical business question:

Where do customers come from?

In the real world, they stroll into the store. In our overused e-commerce example, they navigate to our website. New customers that haven’t used our site before don’t have any cookies or anything we can identify them with. They navigate around, browsing, maybe buying something in the end, maybe not.

Yet, the browsing process is interesting in its own right:

• Which products did they look at?
• Did they use the search feature?
• How long did they spend on each page?
• Did they scroll down to see the reviews?

If and when they do finally buy something, all that history is important and we’d like to maintain a connection to it.

Actually, even before they buy something, what they put in their cart is the interesting piece. The transition from cart to checkout is another interesting piece. Do they actually complete the checkout process, or do they abandon it midway through?

Add to that when we ask/force them to create a user/login in our system.

Are they actually a customer if they haven’t bought anything?

We’re beginning to get an inkling that almost every activity that results in the creation of an entity or storing of additional information can be traced to a transition from a previous business state.

In any transition, the previous state is the aggregate root.

In the beginning…

Let’s start at the very beginning then – someone came to our site. Either they navigated here from some other web page, they clicked on an email link someone sent them, or they typed in our URL. This can be designed as follows:

   1:  using (ISession s = sf.OpenSession())

   2:  using (ITransaction tx = s.BeginTransaction())

   3:  {

   4:     var referrer = s.Get<Referrer>(msg.URL);

   5:     referrer.BroughtVisitorWithIp(msg.IpAddress);

   6:   

   7:     tx.Commit();

   8:  }

   9:   

And our referrer code could look something like this:

   1:  public void BroughtVisitorWithIp(string ipAddress)

   2:  {

   3:     var visitor = new Visitor(ipAddress);

   4:     this.NewVisitors.Add(visitor);

   5:  }

   6:   

This follows the technical guidance we saw at the beginning.

It also allows us to track which referrer is bringing us which visitors, through tracking those visitors as they become shoppers (by putting stuff in their cart), finally seeing which become customers.

We can solve the situation of not having a referrer by implementing the null object pattern which is well supported by all the standard object-relational mappers these days.

How it works internally

When we call a method on a persistent entity retrieved by the object-relational mapper, and the entity modifies its state like when it adds a new entity to one of its collection properties, when the transaction commits, here’s what happens:

The mapper sees that the persistent entity is dirty, specifically, that its collection property was modified, and notices that there is an object in there that isn’t persistent. At that point, the mapper knows to persist the new entity without us ever having to explicitly tell it to do so. This is sometimes known as “persistence by reachability”.

Where validation happens

Let’s consider the relatively trivial rule that says that a user name can’t contain a space.

Also, keep in mind that a registered user is the result of a transition from a visitor.

Here’s *one* way of doing that:

   1:  public class Visitor

   2:  {

   3:     public void Register(string username, string password)

   4:     {

   5:        if (username.Contains(" "))

   6:        {

   7:           DomainEvents.Raise<UsernameCantContainSpace>();

   8:           return;

   9:        }

  10:   

  11:        var user = new User(username, password);

  12:        this.RegisteredUser = u;

  13:     }

  14:  }

  15:   

This actually isn’t representative of most of the rules that will be found in the domain model, but it illustrates a way of preventing an entity from being created without our service layer needing to know anything. All the service layer does is get the visitor object and call the Register method.

Validation of string lengths, data ranges, etc is not domain logic and is best handled elsewhere (and a topic for a different post). The same goes for uniqueness.

Summary

The most important thing to keep in mind is that if your service layer is newing up some entity and saving it – that entity isn’t an aggregate root *in that use case*. As we saw above, in the original creation of the Visitor entity by the Referrer, the visitor class wasn’t the aggregate root. Yet, in the user registration use case, the Visitor entity was the aggregate root.

Aggregate roots aren’t a structural property of the domain model.

And in any case, don’t go saving entities in your service layer – let the domain model manage its own state. The domain model doesn’t need any references to repositories, services, units of work, or anything else to manage its state.

If you do all this, you’ll also be able to harness the technique of fetching strategies to get the best performance out of your domain model by representing your use cases as interfaces on the domain model like IRegisterUsers (implemented by Visitor) and IBringVisitors (implemented by Referrer).

And spending some time on business analysis doesn’t hurt either – unless customers really do fall out of the sky in your world

After blogging since 2003, with over 500 posts I’ve pulled together the “best of the best” for you in the top 3 areas in which my clients use my expertise. Click to skip the introductions.
[ SOA - Domain Models - Smart Clients ]

Service-Oriented Architecture

Before you roll your eyes at me, believe me I do know that SOA has been hyped to death and that you’re probably sick of it. Me too. I’m interested in actually implementing SOA, not just talking about it – it’s actually what I do for a living; from high-level architecture, to detailed design, to choosing frameworks and technologies, and actually building the thing.

What I’ve got online includes podcasts on SOA, webcasts, books I’ve contributed to, full-lenth articles, and open-source frameworks I’ve written to help developers do the right thing by default. So, if you’d like to hear more about the practical aspects of doing SOA, you can jump to the relevant part of this page by clicking here.

Domain Models

You won’t find much of the more theoretical aspects of the domain model pattern or other patterns of application architecture – rather you’ll find presentations I’ve given on the subject, samples, and even an extension to NHibernate. All of these are derived from the work I’ve done around using these patterns – not the least of which is actually making them performant.

Also on the topic of Domain Models and Data Access, you’ll be able to find information on writing highly concurrent systems. This includes an object-oriented development style for service layers that yeild the best multi-user throughput. Jump to the Domain Model section here.

Smart / Rich / Occasionally Connected Client

I know that Microsoft has been pretty active here, putting out the Composite User Interface Application Block (CAB) and the Smart Client Software Factory (SCSF). The only thing is that those are both complex and not thread-safe – I know, I’ve been burned.

So, here you can find the set of patterns, technologies, and frameworks that make for a thread-safe, multi-threaded client that a team can develop in parallel. Jump to the Smart Client section here.

Doing SOA

If you’re tasked with architecting, designing, or implement a Service-Oriented Architecture then the resources below should help you get to the bottom line of all the theory and get you going in terms of actual development.

Podcasts:

• Does SOA mean the end of OO?
• Migrating from N-Tier to SOA
• Does an SOA require an ESB?

If you’d like to more of these kinds of podcasts, check out the “Ask Udi” podcast.

I’ve also be interviewed on SOA on several other podcasts:

• .NET Rocks interview on SOA
• Channel 9’s Ron Jacobs interview on SOA and Workflow

Webcasts:

• SOA Distilled for UML China [PDF] [Audio - 90MB via EMule]
• Why you can’t do SOA without Message [TechEd USA 2005]

Books:

• Applying Domain-Driven Design and Patterns [Chapter] An introduction to SOA
• SOA Expertise – Methods, Concept, & Practice [Article] The ESB and Your SOA—A Great Team

Full-length Articles:

• Autonomous Services and Enterprise Entity Aggregation [MS Architecture Journal]
• SOA Support, Therapy, and Treatment [IBM DevX Portal]

Open Source Frameworks:

• nServiceBus – communications framework for making enterprise .NET systems easier to build

Using Domain Models

If you’re looking for how to implement business logic and data access in your application, then you’ve come to the right place. Here you’ll find the patterns, design, and code that will make your business logic cohesive, your data access simpler, and keep everything performing at its peak.

Introductory info:

• What is a domain model?
• Where should (and more importantly, shouldn’t) you use a domain model
• Don’t tie your architecture to a specific object/relational mapping product [Developer.com]

Make it perform:

• Fetching Strategy Design – UML diagrams describing performance enhancing patterns
• Samples + NHibernate modifications for Fetching Strategies
• Presentation on High-Performance, Persistent Domain Models [TechEd Europe 2007]

Concurrency for multi-user throughput:

• Concurrency for Occasionally Connected Systems [Developer.com]
• Podcast on DataSets and Web Services [ Ask Udi podcast ]
• Realistic Concurrency (difference between optimistic and pessimistic)

Multi-core efficient Smart Clients

If you’re tasked with building a desktop application that communicates with a server, needs to be able to work offline, makes use of multiple cores for a better user experience, and can be developed without having to remember 5 books worth of theory, then this is for you.

Patterns:

• Sample implementation of Model-View-Presenter pattern
• Unit-testing still critical to project success even when using the relevant patterns
• Generic validation using the service locator pattern

Occasional Connectivity:

• Podcast on occasionally connected smart clients (and why ADO.NET Sync Services doesn’t help)
• Passing data from the UI to SOA Services [Podcast]
• Threading issues when smart clients reconnect [Developer.com article]

Thread-Safety = Just-plain Safe

• Explanation of threading concerns when using dependency injection and asynchronous messaging
• Followup on dependency injection, threading capabilities
• Thread-safe, Asynchronous Smart Clients [podcast]
• Prototype of Aspect-Oriented Programming to make views thread-safe by default

So, I’ve implemented the pattern in NHibernate, adding the following method to ISession:

As well as adding the following interface to the NHibernate package:

All this enables you to have a stronger separation between your service layer classes and your domain model class, as well as for you to express each service-level use case as a domain concept – an interface.

Once you have such an interface, you can create a fetching strategy for that use case and define exactly how deep of an object graph you want to load so that you only hit the DB once for that use case.

The nice thing is that its all configured with Spring. In other words, if you the entry for your fetching strategy class exists, you get the improved performance, if it doesn’t, you don’t. All without touching your service layer classes.

Just as an example, when I’m in the use case modeled by “ICustomer”, I want to get all the customer’s orders, and their orderlines. This would be done by having a class like this:

And the configuration would look like this (as a part of the regular spring template):

If you want to take a look at the full solution, you can find it here. For some reason, the combined file was too big for the upload on my blog so it’s split into two. Unzip both packages into the same directory. You’ll find a file called “db_scripts.sql” which contains the schema for the DB. Don’t forget to update your connection string in the “hibernate.cfg.xml”. If you’re looking for the changes I made to the NHibernate source, you can find it in the “Updated NHibernate Files” directory. The only real change is to the “SessionImpl.cs” file.

Relevant NHibernate and Spring binaries.

Source code of example.

BTW, there is some intelligent thread-safe caching going on in SessionImpl now so that you get a much smaller performance hit (in terms of code that uses reflection) on subsequent usages of the same interfaces.

Let me know what you think.

The first is that of keeping Service Layer classes independent of Domain Model classes. The reason this is desirable is that the two families change on independent axis. Service Layer classes are affected by changes to the service’s external interface, as well as the interfaces of other services it depends on. Domain Model classes change to support changing business rules internal to the service. The solution is quite simply to introduce a set of interfaces between the two.

The second is tied to performance. When retrieving data from the database, we’d like to cross the wire only once bringing with us all the data we need in order to perform the work required. Lazy loading helps us in one way while hurting us in another. For connected objects that we don’t need when retrieving our target object, lazy loading prevents them from being loaded. However, for connected objects that we do need, lazy loading will cause us to return to the database to retrieve each of those objects in turn (sets of the same kind of object are still one DB call). If those objects need to be traversed as well in order to retrieve other objects, we can see that one simple request can cause many (MANY!) calls to the DB. These problems of latency and throughput are solved by eagerly (in one DB call) fetching and loading all the objects we need.

Here’s the package diagram for the solution so that we’ll have a reference for the following discussion.

Now, the class that is best suited to issue this call to eagerly load all objects is the service layer class, since it is aware of what specific use case we’re in. However, the service layer class does not necessarily know exactly what classes will be used in the domain to handle that request. Obviously, this set of classes may change as the domain model and the database schema change. We can therefore say that is not the service layer class’ responsibility to handle the definition of which classes need to be loaded. Only the Domain Model has that knowledge. So we need some way to pass the knowledge of the request type into the Domain Model.

In Object/Role Modeling terms, we represent that request type as a role. And roles are represented by interfaces. So we create an interface in the Domain Model which represents the request type. That interface will most likely contain only one method – the method which the service layer class will call.

After we have the first role, we can build other things around it, like fetching strategies. We can then define other classes who fullfil the role of “I’m his fetching strategy”. Those classes will expose a property defining the exact set of classes to load, when using NHibernate we use HQL.

Here’s the sequence diagram showing how this works.

One question that you might ask is what if there is more than one class that implements the same interface? How could the infrastructure know which class it should be loading? The answer is simple. You shouldn’t do that. Having two classes fulfilling the same role will get you in trouble even if you don’t use this design. The Single Responsibility Principle should be our guiding light.

In summary, achieving high performance is possible when using Domain Models and Object/Relational Mapping, but requires minimizing calls to the database. This design decreases coupling between all the cooperating parts of the solution without giving up the ability to optimize over a specific technology.

Download the full detailed design (in HTML format). I’ll be offering the edittable Enterprise Architect format shortly.

There is a different, more OO way of handling this. By separating out the interface of the class you want to be lazy loaded – make an IPerson interface – and have the client code be tied to that. In that way, your dependency injection container (Spring, for example) could instantiate an implementation that handles lazy loading without the client having to know about it. This implementation is absolutely something that could be handled by an OR mapping tool.

So, I suppose that even some of the more difficult problems of OR mapping could be handled. All that is needed is not to add more to the tool itself, but rather to more formally structure how to work with it. My opinion, anyway.

Update

The next part around the discussion about lazy loading and fetching strategies.