2

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?

Jeff
  • 35,755
  • 15
  • 108
  • 220
  • ARs are about transactionnal boundaries, which you need no matter the solution.You would still need event streams t be versioned to protect invariants when there is contention. Not only that but enforcing business rules that depends on the current state of an entity would be hard since you would have to dig through events to reconstruct parts of the state you need (you get that with ARs). The read model is always to be considered stale so that's not an option. – plalx Jun 14 '15 at 21:24

3 Answers3

6

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.

Mark Seemann
  • 225,310
  • 48
  • 427
  • 736
  • So if my application's domain can be defined as a set of commands and events, there's no real reason I shouldn't skip having aggregate roots and domain entities with their own states? (BTW, I greatly respect your opinion on this...) – Jeff Jun 14 '15 at 00:56
3

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.

CQRS And ES Overview

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

Codescribler
  • 2,235
  • 18
  • 22
  • I've actually read that guide! It's very good - nice job. I guess I'm struggling to justify the overhead of the extra layer and boilerplate code... It seems like the AR concept is kind of messy...why not have a simple concept of IConsumer and IValidator, where the Command Handler passes the command to the Consumer, which calls the Validator(s) (which may throw an exception), then creates, saves and publishes events? It would seem like that's more preservative of the SR principle. – Jeff Jun 13 '15 at 19:34
  • 1
    This question has prompted some great input. I like to think I'm fairly pragmatic about these things. Jeff, you seem like a developer with a good amount of experience. That being so, maybe the system you are building doesn't require them. It's worth however, considering what an Aggregate is for. It encapsulates and models behaviour. It does this with (ideally) no dependencies. This makes it a good 'tactical' pattern for modeling behaviour within a bounded context. Oh, and a side benefit, they are relatively easy to test. All useful when modeling a complex system. – Codescribler Jun 14 '15 at 07:17
0

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.

Per
  • 1,061
  • 7
  • 11
  • I've read the first book. It's a good book but doesn't really address my question. There is something in between a CRUD application and one with deeply sophisticated domain operations...and this is usually ignored by DDD texts and authors. In fact, most applications have a combination of CRUD functionality and sophisticated domain operations. What is the need for a domain MODEL in terms of actual entities with state, if a domain itself can really be defined as possible commands and their repercussions (events). Can you give me a concrete example where domain entity classes would be required? – Jeff Jun 13 '15 at 20:38
  • It is required when you work in team with more than one developer and you want your code be easily understood and the reflect business problem your are trying to solve. – Per Jun 13 '15 at 21:00
  • Can you give me an example of why? – Jeff Jun 13 '15 at 21:08