Domain Model with Event Sourcing

Question

Silly question...but why do I need a Domain model at all if I use event sourcing.

I have (an Event Bus of course) and

• Application Services with business operations that each send a Command after basic validation
• Command Handlers which receive Commands perform additional Command validation and publish Events
• Event Handlers which handle Events, update the Read Model, and store the event in a Repository (the Event Source)
• Read Model Services which provide Read Models
• Front ends (UI or otherwise) that consume Read Models from the Read Model Services)...and utilize Application Services for business operations.

Why do I need aggregate roots and domain entities at all? What's the function of the additional layer?

Answer 1

Sounds like you may be doing a bit too much in your command handler. Just to be clear - the role of the command handler is to receive the command, load the appropriate aggregate and to send the command into the aggregate. Finally it grabs any events the aggregate may have generated persists them and finally publishes them. Here is the diagram I have on my blog.

For a fuller step by step overview of a typical CQRS + ES application have a look at my post: CQRS + Event Sourcing - A Step by Step Overview

I hope that clears some things up for you. PS. You may want to take a look at how to create an aggregate root for CQRS and ES. You can find that post here

Answer 2

EventSourcing is simple how you choose to store the state of your application. If you are not solving a specific problem you probably don't need a model of your domain and could just create a simple CRUD application. A domain model is a simplified abstraction of the domain in wich your application is solving a specific business problem. The domain model is tool for communicating between you and your team mates and the domain experts. I would recommend reading this excellent book, or downloading this short introdcution to domain driven design.

Answer 3

You don't.

Domain-Driven Design is about modelling software using a ubiquitous language of domain experts. That model can be a 'relational' model, but it just as much could be a model of Commands and Events.

In a recent interview, Eric Evans explains that he would like to have de-emphasised the tactical patterns (Aggregate Root, Repository, Abstract Factory) etc., and instead emphasised the approach to modelling instead - such as Bounded Contexts.

He also explains how CQRS + Event Sourcing has put DDD into an entirely new light. In many ways, the tactical patterns are a remnant of a past where everything had to be OOP and with an underlying relational database in order to be taken seriously. That was then, but this is now.