Domain Driven Design for security?

I’ve just seen this interesting video of Dan Bergh Johnsson on DDD Security and I must admit that I agree with Dan under many aspect. One of the real advantage of DDD is making business explicit, and this can help in so many places in your software, that even security can benefit of DDD. It is a video I suggest you to watch, because is really small and it can open up a lot of discussion on Value Objects, one of the most useful pattern when you work with DDD.

Gian Maria.

Scan all assembly of the directory to find DomainEvent Handlers and command executors.

Structures based on Commands, Events and respective handler are really flexible and to maximize this flexibility adopting a convention over configuration is the key of success. If you look at this simple playground project you can find that we adopted a convention where a domain handler is any object that implements the IDomainHandler marker interface and any public Method that returns void and accepts a single parameter that inherits from the base class DomainEvent is a method handler. The code to discover handlers is really simple and primitive, but serves the purpose of showing the basic concepts.

var asmName = AssemblyName.GetAssemblyName(fileName);

Assembly dynamicAsm = Assembly.Load(asmName);
Type[] allAssemblyTypes = null;
 try
  {
       allAssemblyTypes = dynamicAsm.GetTypes();
 }
catch (ReflectionTypeLoadException rtl)

Basically I scan all file that ends with dll present in the directory and I try to load it as normal .NET assembly, an outer try catch, catches the BadImageFormatException that is raised if a non .NET dll is present in the directory, the goal is to enumerate all the .NET types of every assembly present in the folder. Next step is finding all handlers.

var handlers = allAssemblyTypes
                    .Where(t => t.IsClass && !t.IsAbstract && typeof(IDomainEventHandler).IsAssignableFrom(t))
                    .ToList();
foreach (var eventHandlerType in handlers)
{

    ParameterInfo[] parameters = null;
    foreach (var minfo in eventHandlerType
        .GetMethods(BindingFlags.Instance | BindingFlags.Public)
        .Where(mi => mi.ReturnType == typeof(void) &&
                        (parameters = mi.GetParameters()).Length == 1 &&
                        typeof(IDomainEvent).IsAssignableFrom(parameters[0].ParameterType)))
    {
        var eventType = parameters[0].ParameterType;

        //I've found a method returning void accepting a Domain Event it is an handler
        MethodInvoker fastReflectInvoker = minfo.DelegateForCallMethod();
        cachedHandlers.Add(new DomainEventHandlerInfo(fastReflectInvoker, eventHandlerType, eventType, _kernel, minfo.Name));
    }
}

Code is really simple, first of all I filter only for types that are non abstract and implements the IDomainEventHandler marker interface, then I scan all methods, to look for method that matched the convention. Thanks to the fasterflect library I create a MethodInvoker that is capable of invoking the method through Lightweight Code Generation, to avoid incurring in performance penalties due to reflection invocation.

This convention is really good because it permits me to write a QueryModel denormalizer with good names for methods.

image

Instead of having three classes each one with an Handle method for each of the domain event I’m interested into, or having a single class with Three method called Handle() and inherits three times the IDomainEventHandler<> interface (one for each type), I can name handlers method giving them business meaning, like CreateInventoryItem, UpdateQuantityOnPicking and UpdateQuantityOnReceived, and a single class is capable of declaring how many handlers he need to do its work. This simple convention makes code really clean without losing the basic structure of run-time binding of DOMAIN EVENT and relative handlers.

Gian Maria.

Convention over configuration, Domain Event and Commanding

If you are moving to a more DDD oriented architecture probably you will adopt a solution that uses Commands and Handlers. Commands are the requests sent to BOUNDED CONTEXT from users or from external systems, they are processed by Command Executors and usually execution is a matter of loading some AGGREGATE ROOT from the store and invoking Methods on it.

Even if you are not using EVENT SOURCING, (Es. you have your AGGREGATE ROOTS persisted on a SQL Database with NHibernate), you should leverage the concept of DOMAIN EVENTS letting each AGGREGATE ROOT to raise one or more DOMAIN EVENTS during execution of its methods. This means that we need to build an infrastructure capable of identifying for each command the single command handler capable of executing that command and for each different type of DOMAIN EVENT the list of Domain Event handlers that are interested in being notified about that event.

When you move from a legacy system to a more DDD oriented pattern you usually proceed one step at a time and probably the simplest solution to implement commanding part of this system is using a Request/Response architecture. This architecture basically solves the problem of binding each command to the command executor letting MEF to handle all the greedy details of scanning assemblies to find Command Executors (you can read all the details on previous posts). When you have such structure in place it seems normal to use the very same structure to manage in-process dispatching of DOMAIN EVENTS.

static DomainEventDispatcher()
{
    var handlers = LoaderHelper.CreateMany<DomainEventHandler>();
    foreach (var handler in handlers)
    {
        Type handledType = handler.CommandHandledType();

        if (!ExecutorsForTypes.ContainsKey(handledType))
        {
            ExecutorsForTypes.Add(handledType, new List<DomainEventHandler>());
        }
        IList<DomainEventHandler> commandExecutorList = ExecutorsForTypes[handledType];
        commandExecutorList.Add(handler);
    }
}

The concept is the very same used for command executor in Request/Response pattern, in static constructor I ask MEF to create all classes that Inherits from DomainEventHandler base class. Domain Event Dispatcher can use this static dictionary of handlers to dispatch the message to the right handler.

if (ExecutorsForTypes.ContainsKey(realEvent.GetType()))
{
    var handlerList = ExecutorsForTypes[realEvent.GetType()];
    foreach (var handler in handlerList)
    {
        handler.Handle(realEvent);
    }
}

The DomainEventHandler class is really simple, and is used primarily to automatically imports with MEF all the types that inherits from it, here its full definition.

[InheritedExport]
public abstract class DomainEventHandler
{
    protected ILogger Logger { get; set; }

    public DomainEventHandler()
    {
        Logger = RepManagement.BaseServices.Castle.CastleUtils.CreateLogger(GetType());
    }

    public void Handle(BaseDomainEvent domainEvent)
    {
        try
        {
            OnHandle(domainEvent);
        }
        catch (Exception ex)
        {
            Logger.Error("Error in handler " + GetType().FullName, ex);
            throw;
        }
    }

    protected abstract void OnHandle(BaseDomainEvent request);

    

Actually I have another couple of intermediate classes the first one is called SyncDomainEventHandler and is used when you want your domain event to be handled in the very same thread of the code that is raising the event and if an handler raises an exception the whole command execution is aborted and a database transaction is rolled back.

I’m hearing you scream “WHAT? Database transaction???”, I know that in DDD architecture usually handlers of DOMAIN EVENTS are completely unrelated to the execution of commands, but actually I’m using this structure in a legacy project based on well known assumptions carved in stone and one of this assumption is that there should be the possibility to execute a series of operations in the domain transitionally.

public abstract class SyncDomainEventHandler<T> : DomainEventHandler where T : BaseDomainEvent
{
    protected override void OnHandle(BaseDomainEvent domainEvent)
    {
        HandleRequest((T)domainEvent);
    }

    protected abstract void HandleRequest(T domainEvent);

    public override Type CommandHandledType()
    {
        return typeof(T);
    }
}

Clearly there is another base class called AsyncDomainEventHandler where the OnHandle instead of directly call the HandleRequest abstract function uses a Task to call it asynchronously. Whenever you write a Domain Event handler you have to choose if your handler is part of the command transaction (inherits from SyncDomainEventHandler) or if it should execute on a thread on its own without affecting command transaction. the vast majority of handlers are Async but very few needs to take part in command execution context. What is happening is that when certain DOMAIN EVENTS are raised, some handler should perform operations that, if failed, should abort the whole command.

In a real DDD architecture, especially if you are using EVENT SOURCING, everything is asynchronous, and if an handler fail its only option is to do a compensative action, but he has not the right to rollback anything.

This structure works, but in the long run it shows some limitation, most annoying one is that we can implement a single DOMAIN EVENT handling method per class, because the class should inherits from a base class and since .NET does not support multiple inheritance, each domain handler class can handle a single DOMAIN EVENT.

In a simple playground project based on CQRS (you can find it here: https://github.com/andreabalducci/Prxm.Cqrs ) we are moving toward a structure based on convention over configuration. In that project the convention is that a domain event handler is a class that implements the interface IDomainEventHandler and defines public method that returns void and accepts a single parameter that inherits from base DomainEvent class.

public class NewInventoryItemCreatedEventHandler : IDomainEventHandler
{
    protected ILogger _logger;

    public NewInventoryItemCreatedEventHandler(ILogger logger)
    {
        _logger = logger;
    }

    public void ReactToInventoryItemCreated(InventoryItemCreated @event)
    {
        _logger.Debug(string.Format("[inventory] item {0} has been created and handled", @event.Sku));
    }
}

This is much more interesting way to bind handlers to DOMAIN EVENTS. The IDomainEventHandler class has no method and is only a marker class, you can use an attribute if you prefer or you can completely remove this requirements and consider a domain event handler each class that defines public method that returns void and accepts a single argument that inherits from DomainEvent, but usually having a marker class or an attributes explicitly declared in the class prevents from bad surprise. The primary advantages is that you can define how many handler methods you need in the same class, so your handlers are better grouped together. As an example all denormalizers that manages Query Model in CQRS architecture usually needs to handle several related DOMAIN EVENT to maintain a single Query Model, with this infrastructure you can define a single class that manages a QueryModel and that handles all the DOMAIN EVENTS he needs.

In subsequent post I’ll show how simple is to create a class that manages loading and discovering of Handlers based on this convention.

Gian Maria.

Poor Man DDD

Some of my friends are doing great stuff with DDD but it is difficult to do DDD in legacy projects that last for years and started with a classical structure of UI+domain(anemic)+ORM/DAL, so it seems that exploring the fascinating land of DDD is an option only for people that start to work on new project, but it is really true? Clearly the main advantage of DDD is not related to technical questions, but it is to be found in the approach to problem: dialogue with DOMAIN EXPERTS, establishing an UBIQUITOUS LANGUAGE, and so on, but some of the grounding technical concepts of DDD can be inserted in legacy applications built with standard techniques to bring some of the advantages of DDD in existing projects.

If you think to CQRS it can be considered an evolution of the classic separation of databases to satisfy OLTP and OLAP needs, you usually have high normalized database for transactional processing, then you move data in a complete different database that is highly denormalized to satisfy reporting queries and if you have really complex structure you usually move to a OLAP Cube.  The key concept is that you have two different model, one for reporting (and it is usually stale) and the other for all the rest of the system, and it worked damn well. Now consider CQRS is a natural evolution, because it advocates separation of a Write and Read model for the remaining part of the system. Whenever you need to modify data you should use the Write model and when it is time to Read data you should use a Read model, period.

This approach greatly simplify your code, because using a single model to read and write usually creates a lots of problem related with: ORM, mapping, profiler, and you start spending time to avoid incurring in performance penalties (Es. N+1 select), or how to create a NHibernate query for unrelated entities and so on. Life is really easier if your domain is designed for Write and you build a complete different domain to Read data, the key to reach this level of abstraction is the introduction of Domain Events. In one application I’m working on, we have a Denormalized version of data used for reporting that is result of some analysis, it usually gets populated at the morning so it contains stale data by one day. Now the software evolves, and some of the data that are taken from this denormalized database needs to be updated more often. The first solution that come in mind is running the scripts that populates this database more often, but since these script are designed to move large portion of data (one day of work) they are not meant to be run once minute or once 5 minutes.

Then I realize that this solution is not meant to solve the original problem, because talking with DOMAIN EXPERTS and asking them their needs, they simply told me: when I do this I want that data to be available as soon as possible in the report. The real need is that when a certain DOMAIN EVENT happens in the system, the analysis should start immediately generating another DOMAIN EVENT that tells that the analysis is finished and finally when the analysis is done I can update the denormalized database.

This reinforced my belief that DOMAIN EVENTS are the primary concept to move the core of your system from a legacy structure to a more DDD oriented architecture I’ve called this Poor Man DDD, because it lacks too many concepts of DDD, and most of the domain is still too interconnected and too much anemic, but at least the CORE DOMAIN is moving to a less coupled architecture. The key concepts is that Any modification that happens in the CORE DOMAIN should create a DOMAIN EVENT, this capture the When I do this part of the above sentence. This guarantee that your system has a log system written in UBIQUITOUS LANGUAGE, and this is the main advantage of introducing DOMAIN EVENTS. Now you have a lot of way to elaborate this stream of DOMAIN EVENT, you can simply attach HANDLERS that capture the I want that data to be available part and this perfectly solves your original problem.

Now we can answer to problem in more simpler way. When we need to add a behavior to the system related to some operation, people usually starts to think where to put that behavior, in the domain object? In the service call that manipulates the DOMAIN (anemic)? Create another service method and call it from the UI after the call to the original method (scattered logic)? Suppose the requirement is when I update the entity X you need to do some analysis only when the status change from Active to Confirmed. You have a lot of Choices. If your domain is not anemic probably you have a Update method directly in the entity, so you can put an if (oldstatus == active && newStatus == Confirmed) condition and write your code there. If the domain is more anemic probably you have a UpdateXXX in some service and you can put the same condition there, or you can work at UI level putting the condition after the call to UpdateXXX service method and call a new service method called DoAnalysisOnXXX() .

From a DDD perspective putting logic in the UI is the least appealing choice, putting it in Service Method call is not so good because you are creating an ANEMIC DOMAIN and the best solution seems to have an Update method in the entity with all the logic inside it because this is real DDD, after all the logic is in Domain Object, how it can be better?  In the end I’m convinced that all three solution are not so good, because none of then capture the real important fact happened in the domain, the change of status of the XXX entity. If you concern regards only “where I put the logic” you are probably facing the wrong problem. The subtitle of Eric Evan’s book is takling complexity in the Heart of Software, but it does not mean to have ultra complicated Domain Classes that models a complicated business. The risk of storing all the logic inside Domain Classes is having really complex beasts that are almost unable to tame. My system should model my business, and my primary concern is not where I put the code, but how good is my code in modeling my business, and if you start to think with this perspective the question “where I put my logic” is not a problem and it is not the real goal of DDD.

The value of DDD is in speaking with DOMAIN EXPERTS, and the above requirements immediately tells you that the fact that entity X move from Active to Confirmed is something interesting for the business, and it should be modeled with a DOMAIN EVENT. Now you should start to have a better model, and maybe you discover that the important fact is that the destination status is Confirmed, because it models an important step in the real business,  and you can decide to create: ConfirmedXXX and XXXUpdated distinct DOMAIN EVENTS, the first capture the Confirmation and the latter capture a generic change in the properties of the XXX entity. Now it is supereasy to decide where to put the analysis code: in an DomainEventHandler<ConfirmedXXX> handler. When you start to think in term of events you will find that you are able to solve problem with less and easier code and the complexity usually diminish.

In the end even the single introduction of DOMAIN EVENTS into a core part of a legacy system can really bring lot of benefits. The next step is Poor man CQRS. :P

Gian Maria.

SimpleCQRS appliers and convention over configuration

I was playing around with SimpleCQRS project because my friend Andrea started to work on it recently. We now have Mongo repository for the events so I forked the project to have a look on it and contribute to Andrea works. I’ve opened the solution, ran the program, created some InventoryItems, then I look into mongo database to verify if snapshot of objects are correctly taken but I found this.

image

Figure 1: Snapshot of objects inside mongo

All snapshot are null, so I started investigating to understand the root cause and the reason is in this code

public InventoryItem(string id, string description)
{
    Apply(new InventoryItemCreatedEvent(id, description)
                {
                    AggregateRootId = Guid.NewGuid()
                });
}


protected void OnItemCreated(InventoryItemCreatedEvent e)
{
    this.Id = e.AggregateRootId;
    this.ItemId = e.ItemId;
    this.Description = e.Description;
}

Can you spot the problem? The fact is that such kind of problem is difficult to spot out because of the convention that were choose to apply EVENT SOURCING. First of all remember that in an architecture based on event sourcing the change of status of objects are done reacting to a DOMAIN EVENT, thus when you call the constructor of InventoryItem it calls the method Apply() on the AggregateRoot passing the DOMAIN EVENT that contains all the information about the creation of the object, then the AggregateRoot in turn should call the method OnItemCreated that actually do the real change of status. This tricky code is necessary because it should be possible to reconstruct the object from the stream of events he generated in the pase, so you need to decouple the method that contains the business logic (the constructor in this example) from the method that perform the change of status, lets call it the applier method. With such a structure if you want to reconstruct the state of the object you can simply reload all events from the event store and reapply to the object calling OnXXXX methods.

Now the original problem can be spotted if you look at the Apply() method of the AggregateRoot() that in turn calls ApplyEventToInternalState.

private void ApplyEventToInternalState(DomainEvent domainEvent)
{
    var domainEventType = domainEvent.GetType();
    var domainEventTypeName = domainEventType.Name;
    var aggregateRootType = GetType();

    var eventHandlerMethodName = GetEventHandlerMethodName(domainEventTypeName);
    var methodInfo = aggregateRootType.GetMethod(eventHandlerMethodName,
                                                    BindingFlags.Instance | BindingFlags.Public |
                                                    BindingFlags.NonPublic, null, new[] {domainEventType}, null);

    if(methodInfo != null && EventHandlerMethodInfoHasCorrectParameter(methodInfo, domainEventType))
    {
        methodInfo.Invoke(this, new[] {domainEvent});
    }

    ApplyEventToEntities(domainEvent);
}

As you can see the base class use reflection to find a method in the class that have a specific method name that is determined by the GetEventHandlerMethodName() method

private static string GetEventHandlerMethodName(string domainEventTypeName)
{
    var eventIndex = domainEventTypeName.LastIndexOf("Event");
    return "On" + domainEventTypeName.Remove(eventIndex, 5);
}

This means that if the event is called InventoryItemCreatedEvent the corresponding applier method must be called OnInventoryItemCreated, and if you misspell the name, the method is simply not called and the object does not change status. Now look again to the original piece of code of InventoryItem domain object, and you will find that the applier method is mistakenly called OnItemCreated, this means that it gets never called, and the object never change state. What happened in this situation is that you will end with an InventoryItem that has null ItemId and null description and this is the reason why all data in the snapshot is null.

I really do not like this convention; what happens if I call my domain event something like OrderShippedEventMaster? I can agree that this name is not so good for a domain event, but if you look at the GetEventHandlerMethodName you fill find that probably you will have to do some string math to understand how the applier method should be called. In my personal opinion this violates the principle of least surprise, and can lead to annoying bug difficult to spot when you are developing. So I decided to do a really little modification

public InventoryItem(string id, string description)
{
    RaiseEvent(new InventoryItemCreatedEvent(id, description)
                {
                    AggregateRootId = Guid.NewGuid()
                });
}

protected void Apply(InventoryItemCreatedEvent e)
{
    this.Id = e.AggregateRootId;
    this.ItemId = e.ItemId;
    this.Description = e.Description;
}

I’ve modified the method of AggregateRoot from Apply to RaiseEvent that sounds more correct to me, and I’ve changed the convention of the applier method, simply stating that an applier method should be called Apply and it must accept a single parameter that represent the related DOMAIN EVENT that this method will apply to the internal state. This convention is more natural in my mind, because the binding from the applier method to the DOMAIN EVENT is naturally expressed by the parameter of the method, and you do not need to do any strange string manipulation to understand how the event should be called. I’ve also added Lightweight Code Generation to make invocation of applier method faster, because calling GetMethod for each applier is not the best idea in production code.

Now I fired the UI again, created an InventoryItem and now I can see correct result in the Snapshot collection in Mongo database.

image

Figure 2: Now that I fixed the applier method the new object I created is now correctly saved in the snapshot because it correctly change the state reacting to the InventoryItemCreatedEvent DOMAIN EVENT

Convention over configuration is really a good strategy for your software, but conventions should be chosen with great care, because complex conventions can lead to tricky to find bugs.

Gian Maria.