get aggregate id based on its data in it

Question

I have an aggregate root called SizeRangeAggregate which holds the range of size of clothing piece dimension and price for that range. I created an post rest API which create new SizeRangeAggregate. It follows the CQRS/ES which means

1. it creates CreateSizeCommand
2. publish it to CreateSizeCommand command handler
3. generate SizeRangeCreated event
4. persist the event to eventstore
5. publish the event to SizeRangeCreated event handler where the read model is generated called SizeRangeReadModel

I want to add a simple domain logic where an API will not create a new SizeRangeAggregate if the range is already defined in other SizeRangeAggregate.

Currently I am using the read model range filter (something like getByRange) in API controller to get the SizeRangeReadModel if exist, before creating CreateSizeCommand . But I think I am doing it wrong as this is a domain logic and thats why should not be in controller.

Could you suggest me best option/ way to implement this.

Answer 1

But I think I am doing it wrong

You've got good instincts. There's a lack of clarity in the thinking around this scenario and everything will be easier if we can clean that up.

I have an aggregate root called SizeRangeAggregate which holds the range of size of clothing piece dimension and price for that range.

Okay, so I'm imagining your class is something like:

class SizeRangeAggregate     {   
  size SmallestSize = size.Small;   
  size LargestSize = size.ExtraExtraLarge;   
  currency Price = $0.00; }

So, what's the problem here?

The problem is that this is not an aggregate root -- or, to truncate a little less -- this is not an aggregate root entity.

This is not an entity at all.

This is a value object.

If you accept this as now self-evident, it should raise further questions:

• What does it mean to 'create' a 'new' value object by POST?

• What does it mean for a value object, or a piece of a value object, to 'already exist'?

It might be easier to think of these questions in the context of a more-universal, less-Domain-bound value object -- like Dates, for example.

Better thinking around these questions and the role of this particular Value Object within this particular Domain should make everything much clearer.

(To hazard a guess at a Domain that I know nothing about, I might guess that the actual Entity you want to deal with is something like a set of non-overlapping SizeRanges at a particular point in time, and your operations will consist mostly of querying this set and adding or removing set items.)

Answer 2

But I think I am doing it wrong as this is a domain logic and thats why should not be in controller

Although it is domain logic it is a requirement that affects multiple Aggregates, so a service is the place to put the code. But, this business requirement is implemented mainly using technology/infrastructure, so the domain logic can be implemented with simple code that looks like this:

if(repository.theAggregateDoesNotYetExist(some, data))
    sendCommand(createAggregate)

The simplest solution is to put this code in the Application service that normally sends the command.

I do it another way. My CQRS framework has the concept of command validators. These are components that intercept the commands and, if the context does not permit them, they reject them. I don't use command validators to protect business rules that should be checked inside the Aggregates. Command validators are also eventually consistent so they don't protect from concurrent inserts. Together with a Saga they can eventually bring the entire system in a permitted state.

Command validators help following the Open-closed principle (you can add as many business rules you want without modifying existing code) and Single responsibility principle (they validate only one command for a single business rule).

The way this pattern is implemented is by decorating the CommandDispatcher.

Answer 3

I want to add a simple domain logic where an API will not create a new SizeRangeAggregate if the range is already defined in other SizeRangeAggregate.

This sounds like a case of Set Validation; Greg Young reviews the details well.

We talk about event streams as though they are tied to an aggregate, but the truth is that they are much closer in practice to the write ahead log of a database. Deciding that each aggregate has its own stream is analogous to saying that each aggregate lives in its own (logical) database.

(If you consider an RDBMS; it's easy to constrain all of the rows of a table in one database, but it is much more challenging to apply that constraint across two different databases).

If each aggregate has its own unique stream, then verifying a constraint across the set of aggregates at the moment of write isn't going to happen. You can use views -- copies of information prepared by reading from multiple streams as a surrogate for an absolutely correct check, but there will be race conditions that lead to conflicting writes that you will need to resolve later.

Within the domain model, this view would normally be represented as a domain service -- it would provide an API to let you know if a given range is unique to a cached set of ranges, and the domain logic could use that information.

But the risk that the cache is out of data never really goes away.

This is why the critical question is

what's the cost to the business?

If this validation is something critical to the business, then you need a domain model that supports it -- and that's not a model where the set is distributed into multiple independent parts.