Add AggregateRoot<TId>

[xavierjohn]

Add AggregateRoot<TId>

Inheriting from this class gives clarity to the consumer group of all the Aggregate Roots

[hankovich]

Adding AggregationRoot was discussed in #453 and it was decided that it should not be a part of this library. Check #453 (comment) please.

[xavierjohn]

The other PR has IAggregateRoot and IEntity interfaces, and I am not sure of why an Interface is needed.

On the other hand, this library has already mixed two concerns, DDD & Functional programming. We could say that Entity, ValueObject, SimpleObject, and Enum all belong in a separate library.

Given where we are today, I think adding this class that only adds documentation value belongs here.

[vkhorikov]

The AggregateRoot and IAggregateRoot can be implemented in the consumer's code. The AggregateRoot is simple, so there's no real need to put it into this library (or any library for that matter). Libraries are good for complex things; simple stuff can be just copied over from project to project.

Also, regarding the mish-up of DDD & Functional programming. That's true, but let me give context for future reference.

Initially, the library contained only Result, Maybe, and ValueObject. The first 2 are obviously related to functional programming. ValueObject belongs to both functional programming and DDD. In functional programming, you also wrap primitive types into domain-related classes to make illegal states unrepresentable.

I resisted adding Entity for a long time, but eventually gave in, mostly for symmetrical purposes (since there already is the Value Object base class). I'd really like to stop here and not add any other DDD-related base classes. Especially because, unlike Entity and ValueObject, they are simple.

[xavierjohn]

Is Entity an RDBMS leaked implementation detail? If I was using a document DB to store the aggregate, would I have entities with IDs? It will be interesting to see DDD training without using an RDBMS. In my case, I am using CosmosDB, so I only have aggregates and ValueObjects.

[vkhorikov]

Good question. I'm not 100% sure, but I think I would, just for unification purposes.