Difference between an entity and an aggregate in domain driven design

Question

Please what is the main difference between entities and aggregate roots in domain driven design. For example in entity framework, what is the use of aggregates if I can ensure data integrity entities?

Koester

Answer 1

From domain driven design perspective DbContext is the implementation of UnitOfWork and a DbSet<T> is the implementation of a repository.

This is the point where DDD and EntityFramework contrast. DDD suggests to have a Repository per aggregate root but EntityFramework creates one per Entity.

So, what is an aggregate root?

Assume that we have a social network and have entities like Post, Like, Comment, Tag. (I believe you can imagine the relations between these entities) Some of the entities are "Aggregate Root"

To find the aggregate root(s) I try to find which entities cannot live without the other. For instance, Like or Comment cannot live without a Post. Then Post is an aggregate root and we need a PostRepository or turn the Post entity into a Repository (the famous collection like interface thing). CRUD operations for Comment and Like (as well as the Post) should remain on this repository.

Sterigma

Good answer and definition, a much more functional definition rather than my theory definition. – Foliage

'DDD suggests to have a Repository per aggregate...' an excellent, and under-utilised concept, IMHO. – Felton

@Mehmet Nice description. Exactly the picture I had of aggregate roots. I thought this is possible with database table entities generated using entity framework, with regards to foreign keys and primary keys. Would it be wise to let entity framework generate entities for a domain driven design project? or manually build one?.....Finally how can I persist aggregate roots to a database? – Koester

"For instance, Like or Comment cannot live without a Post" That's a very naïve way of composing aggregate boundaries. Following this thinking will lead to large cluster aggregates, even though it's completely unnecessary. Do you really need to load all comments made on a Post in memory just to add a new one? What invariant are you trying to protect by doing so? You may need this in some domains, but that design would be wrong for most blogging applications. – Galantine

@Koester Honestly, I never used EntityFramework along with a DDD approach and I do not want to mislead and confuse you about the implementation details. Someone with this experience may answer your questions better than me. – Septuor

@Galantine You are right! This is only for giving a basic understanding. As the domain grows this simple approach will cause very bad designs and further analysis will be required to design domain. But for the beggining, I believe, that's something one should know. – Septuor

This is very late though...but this article helped my understanding further. [link] (codeproject.com/Articles/1020932/…) – Koester

Can u please describe more: I try to find which entities cannot live without the other. what do u mean by live? – Liquesce

@AlirezaRahmaniKhalili You can think it like this. When you delete a Comment, does it make sense to delete the Post as well? Probably not. Then it means Post can live without Comment. On the opposite side, does it makes sense to delete the Comments when a Post gets deleted? Probably yes. Then it means Comments cannot live without a Post. – Septuor

This answer only identifies Value Objects and Entities. Why is Post an Aggregate Root? Sure if the system only has these three objects. What if there is an author? An author has to write the post (post cannot exist without any author then.) So which one is the aggregate root? – Ludewig

@Ludewig the way I like to think about it is whether you should be able to access said information using only its own id. For example in the case of the post, if you want to have a url such as: myforum.com/posts/123 then post with id 123 needs to be directly accessible without further info. Author would be the same. Author could reference another aggregate (post) and post could reference the author. – Firearm

@Firearm I have to disagree with your approach. If you allow updating the author of a post to another author, that is just wrong. Yes, in terms of database that would make sense. But an author writes a post, it can't belong to another author unless it is a marketplace where an author can sell a post (think properties/houses) to another author. – Ludewig

@Ludewig I agree that you should not include an entity in multiple aggregates but you can reference it through its id. Just reference it not include the whole thing. By author being the same, I meant that you could find the author directly through myforum.com/author/332 although in the post aggregate only the author Id would be referenced and would not include things such as the author's name. – Firearm

Answer 2

Entity: An object defined primarily by its identity is called an ENTITY that has significance (e.g. Customer) in the sales system is an Entity and can change over time.

Value Object: Value Objects are objects that are known only by their properties and values. For example, "Customer Address" can be designed as a Value Object. Value Objects can be assigned to different Entities and are usually implemented as Immutable (e.g. date, address)

Aggregate: a collection of entities or value objects that are related to each other through a Aggregate Root object

Aggregate Root: Each Aggregate has a root and a boundary, Aggregate Root owns an Aggregate and serves as a gateway for all modifications within the Aggregate

Foredeck

Answer 3

The definition is fairly straight forward:

• Aggregate: Basically a cluster of objects, that create a clear reference to the root aggregate, to so when you reference the root, you can ensure integrity of the aggregates as a whole.

Aggregate is a pattern in Domain-Driven Design. A DDD aggregate is a cluster of domain objects that can be treated as a single unit. An example may be an order and its line-items, these will be separate objects, but it's useful to treat the order (together with its line items) as a single aggregate.

An aggregate will have one of its component objects be the aggregate root. Any references from outside the aggregate should only go to the aggregate root. The root can thus ensure the integrity of the aggregate as a whole.

Aggregates are the basic element of transfer of data storage - you request to load or save whole aggregates. Transactions should not cross aggregate boundaries.

DDD Aggregates are sometimes confused with collection classes (lists, maps, etc). DDD aggregates are domain concepts (order, clinic visit, playlist), while collections are generic. An aggregate will often contain mutliple collections, together with simple fields. The term "aggregate" is a common one, and is used in various different contexts (e.g. UML), in which case it does not refer to the same concept as a DDD aggregate.

• Entity: In a data model context, describes the structure of data regardless of the stored form.

The EDM addresses the challenges that arise from having data stored in many forms. For example, consider a business that stores data in relational databases, text files, XML files, spreadsheets, and reports. This presents significant challenges in data modeling, application design, and data access. When designing a data-oriented application, the challenge is to write efficient and maintainable code without sacrificing efficient data access, storage, and scalability. When data has a relational structure, data access, storage, and scalability are very efficient, but writing efficient and maintainable code becomes more difficult. When data has an object structure, the trade-offs are reversed: Writing efficient and maintainable code comes at the cost of efficient data access, storage, and scalability. Even if the right balance between these trade-offs can be found, new challenges arise when data is moved from one form to another. The Entity Data Model addresses these challenges by describing the structure of data in terms of entities and relationships that are independent of any storage schema. This makes the stored form of data irrelevant to application design and development. And, because entities and relationships describe the structure of data as it is used in an application (not its stored form), they can evolve as an application evolves.

The definition may vary, those are defined by Martin Fowler and Microsoft. Hopefully that clarifies the difference though.

Foliage

The definition's for both are sadly used interchangeably, which can be confusing but that is what each actually means. – Foliage

Answer 4

Aggregate contains invariants and Entity not, that's it. To create an aggregate you need to have at least one invariant.

Here's a guide on how to use invariants to find your aggregates.

Link

Harmon

Thanks for your contribution. really appreciated – Koester