Auto-Incrementing Ids assigned from repository

[zacharyweidenbach]

First of all, thank you for this repository. I reference it often.

My question is around auto-incrementing IDs assigned by the DB, and it's affect on the design of aggregates, and their domain events. For instead, if an aggregate is created, the create method for that aggregate might return an instance of the aggregate where it's id is null. This would push a domain event into it's event list without a proper identity. Then, when the repository saves the aggregate, it would try to publish the domain event without the proper identity attached to it. When the repository is responsible for assigning the id, does it make sense to tightly couple the domain event management to the aggregate root class anymore?

The alternative I can think of, is to instead have a Domain Service with a create method that isolates the domain event management from the use-case that would call into it, and the domain aggregates themselves no longer contain functionality to manage domain events. But this would seem to break the rule that Domain Services are for operations that require 2 or more entities to perform their task.

The other option I can think of is to still have a random UUID for the id, and a separate id assigned by the system, but it seems like a hefty tradeoff to introduce two mechanisms for determining uniqueness of an entity. Any insight would be greatly appreciated!

[Sairyss]

Auto-incrementing IDs for aggregates have some disadvantages:

• exposing auto-incrementing IDs is a bad practice since it can leak data (for example if user creates an order and sees that id is 1000, he will know that your company has 1000 orders, which is not desirable information to expose) or can be exploited in many other ways
• auto-incrementing ids are not globally unique

It's a common practice to use 2 ids in databases, a primary key and a surrogate key, so you can have both.

If you still want to stick to auto-incrementing ids, just change the code accordingly to support it (maybe publish events after aggregate is saved and id is issued).

[zacharyweidenbach]

I was looking for guidance on ways to adapt your design to such a use case. "just change the code accordingly to support it" sort of glosses over the fact that the aggregate root class can no longer ergonomically abstract away the domain event list. So the design would need to fundamentally change. That is, unless the repository mutates the aggregate's domain event list with the newly issued id. I've attached a diagram to illustrate the problem.

It seems with auto-incrementing Ids, it intractably couples your domain to your repository, such that the state of the domain aggregate depends on the repository to issue it an id. Therefore, domain aggregates cannot be the sole owners of domain events anymore. Domain event logic must be lift a level higher, to some orchestration level like a Domain Service, such that the event can be sensibly created and published after the aggregate has been persisted and issued an id by the repository.

[zacharyweidenbach]

Another option would be to have some kind of "commit" method that creates the domain event instead. But this is really allowing technical complexity to creep into the domain, I feel.

[zacharyweidenbach]

The solution I came up with (I'm working in java, so I'm only taking inspiration here) is to modify the AggregateRoot's publishEvents method to also take an aggregate Id argument. Each of the domain events are extended from a DomainEventWithAutoId base class that has an issueId method that allows a caller to mutate the domain event's Id (I could make it immutable with more work). So, the create method stores a domain event where the id is null. Then, when the repository saves the record and gets an id back, it issues it to the aggregate via aggregate.publishEvents(eventPublisher, savedAggregateId). Within that method, it iterates over all the domain events it has locally and calls event.issueId(savedAggregateId) before emitting the event.

That way, the Aggregate can still encapsulate the domain event management, and the repository can preserve it's contract of emitting events when they are saved (and the wrapping transaction is complete).