The Artima Developer Community
Sponsored Link

.NET Buzz Forum
Event Sourced Aggregates Part 2: Where the mess starts

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Christian Horsdal

Posts: 253
Nickname: horsdal
Registered: Mar, 2009

Christian Horsdal is a software architect at MjĂžlner Informatics.
Event Sourced Aggregates Part 2: Where the mess starts Posted: Oct 31, 2017 4:09 PM
Reply to this message Reply

This post originated from an RSS feed registered with .NET Buzz by Christian Horsdal.
Original Post: Event Sourced Aggregates Part 2: Where the mess starts
Feed Title: Horsdal
Feed URL:
Feed Description: A blog that will be about code, architecture, design, and .NET.
Latest .NET Buzz Posts
Latest .NET Buzz Posts by Christian Horsdal
Latest Posts From Horsdal

In the first post in this series I outlined a typical C# implmentation of  event sourced aggregates. In this post we add a second feature to the example from the first post. In doing so I wish to illustrate how that typical implmentation leads to violation of Open/Closed principle and ever growing aggregates.

The second feature

Once we have the code from the first post in place - that is: The infrastructure for sending commands to aggregates, raising events from aggregates, saving events and replaying events - and need to add a second feature, the way to do it is (to some extent) as outline in the foirst post: 
  1. Send a new type of command
  2. Implement a command handler for the new command
  3. Implement a new method on the aggregate with the new domain logic
  4. Emit any new events needed
  5. Implement new When methods for any new event types
Let's say we want to be able change a users username.
The command and the sending of of that command looks like this:

That's pretty straight forward and not too interesting, so let's move on to the command handler:

That also pretty straight forward, but a little more interesting: Most of the the command handler code is something that will be repeated in all commands handlers. We will deal with this in the next post, where that repetition is pulled out into a helper class.
The next step is changes to the aggregate, where this is added:

This is still pretty straight forward. In fact everything needed to add this new feature was straight forward, so that is a good thing. The problem lies in the last two methods, the ones added to the aggregate.

Problem: An Open/Closed Principle violation

The aggregate just grew. In order to support changing the username we added 2 methods to the aggregate. That violates the Open/Closed principle, which indicates that it is a potential problem. In my experience, it quickly becomes a real problem because the aggregate grows relatively quickly and eventually becomes big and complicated, just like any other class that grows monotonically.

That's it for now. The next posts will:
  1. Make the command handlers smarter and clean up some repetitiveness
  2. Make the aggregate anemic in a naive way, leaving a stable aggregate, but introducing a new Open/Closed violation
  3. Make the aggregate anemic, events (a little) smart, and solve the Open/Closed violation

Read: Event Sourced Aggregates Part 2: Where the mess starts

Topic: Event Sourced Aggregates Part 3: Clean up command handlers Previous Topic   Next Topic Topic: Event Sourced Aggregates Part 1: Outline of a typical implementation

Sponsored Links


Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use