How to approach sub entities

[botagar]

Good existence all~!
I'd like to preface my following questions with the statement: "Everything being asked is in the context of implementation within the cqrs-es framework, using the same tech stack as the postgres example project."

So I'm having a crack at doing something using the CQRS technique for the first time.
I've read many articles, done some domain mapping, cracked open the blue book and have picked cqrs-es as my first shot into this world.

Following the example project is simple enough for a simple domain object but I'm finding things get unwieldy as soon as you start adding more fields and entities.

Let's take the problem of an event management system:

• Event has:
  • Name
  • DateTime
  • Host (host_id)
  • Location(s)
  • Checklist(s)
  • Attendee(s)

Event here is the Aggregate.
Name is a "native" string property.
DateTime is... DateTime.
Host is referencing a "Person" aggregate somewhere else through its ID.
Locations, Checklists and Attendees are collections of Entities, where each Entity has their own set of properties.

Example of Location entity:

• Location has:
  • Id
  • Name
  • Address
  • Google Maps Link
  • Instructions

So far, on the theoretical front, nothing in the design causes alarm in my (admittedly inexperienced) thoughts until I actually go to implement it.
To me, there's obvious boundaries to the commands to interact with the aggregate:

• CRUD on the Event native properties
• CRUD on each of the Entity Types

Following this, I would end up with at around 16 commands, and each command when implemented lands in at around 30 - 50 lines of code (yes, the heavy lifting logic is done inside the services, not touching on those here) depending on the number of properties in the entity and we end up with... 500 - 800 LoC in a single file on just CRUD actions.

THEN... you add in tests, and I find the tests also land in at around 30 - 50 LoC per test case. This quickly blooms into thousands of LoC all in a single file.

With my background in "enterprise" "OOP" software, seeing a file with a few thousand lines of code gives me the knee-jerk reaction of "kill it with fire".

And thus I'm here now.
I don't think I carved this example badly, but I feel like I'm missing something in the implementation.
Things like the "Location" or "Checklist" aren't things that are big enough or important enough to exist as their own aggregate; They make no sense (in the broader domain) on their own.

Have I misunderstood something here?
Am I missing an important step somewhere?

Help would be appreciated to get my head around this.

Cheers~!

[davegarred]

Hi @botagar, a few of my thoughts.

Try to avoid thinking in CRUD terms, this pattern does not translate well and CQRS is not a good tool for a system this simple. Commands and events should be small and specific. If location is an entity of import, rather than an UpdateLocation, I would expect much more specific set of commands to complete these tasks, e.g.,

• MoveLocationAddress
• ChangeLocationLink
• UpdateLocationInstructions

This assumes that there is more complex business logic around these Locations than a simple value replacement, e.g., changing the location address may require notifying all of the current attendees. If that additional complexity is not needed then CQRS may not be the best choice of tools here.

(yes, the heavy lifting logic is done inside the services, not touching on those here)

All of your business logic should be in the Aggregate, particularly the complex stuff. This is where DDD diverges from the sort of logic that you find in many Enterprise Java applications. In any DDD application, services are only there to provide some outside information or perform a task on another system.

seeing a file with a few thousand lines of code gives me the knee-jerk reaction of "kill it with fire".

As it does to all of us, please don't concentrate your aggregate logic in a single file. A larger system might be better suited to use an entire module for the aggregate logic.