Difference between an entity and an aggregate in domain driven design

Solution 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.

Solution 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

Solution 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.