Aggregate root is a complex name for simple idea.
Well designed class diagram encapsulates its internals. Point through which you access this structure is called aggregate root
.
Internals of your solution may be very complicated, but user of this hierarchy will just use root.doSomethingWhichHasBusinessMeaning()
.
If you think that option A is better then congratulations. You get main reason behind aggregate root
.
Imagine you have a Computer entity, this entity also cannot live without its Software entity and Hardware entity. These form the Computer
aggregate, the mini-ecosystem for the Computer portion of the domain.
Aggregate Root is the mothership entity inside the aggregate (in our case Computer
), it is a common practice to have your repository only work with the entities that are Aggregate Roots, and this entity is responsible for initializing the other entities.
Consider Aggregate Root as an Entry-Point to an Aggregate.
In C# code:
public class Computer : IEntity, IAggregateRoot
{
public Hardware Hardware { get; set; }
public Software Software { get; set; }
}
public class Hardware : IEntity { }
public class Software : IValueObject { }
public class Repository<T> : IRepository<T> where T : IAggregateRoot {}
Keep in mind that Hardware would likely be a ValueObject too (do not have identity on its own), consider it as an example only.
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.
For more details see the Domain-Driven Design book
.
Background
An Aggregate is an object or collection of objects (Entities and Value Objects) that must be treated as a single unit for the purposes of a business transaction. The Aggregate will maintain all invariants for all objects that comprise包含;由…组成 the Aggregate, enforcing all business rules internal to the Aggregate.
Aggregate Root
All Aggregates have a single point of entry that is know as the root. The Aggregate Root is the interface to the external world. All interaction with an Aggregate is via the Aggregate Root. As such, an Aggregate Root MUST have a globally unique identifier within the system. Other Entites that are present in the Aggregate but are not Aggregate Roots require only a locally unique identifier, that is, an Id that is unique within the Aggregate.
For example: an Order will contain Order Lines. The Order is the Aggregate Root and must have a unique Order Id. The Order Lines cannot be accessed directly. Any updates to Order Lines must be via the Order. That is, you ask the Order to make the change to ITS Order Line. An Order Line is only required to be identifiable with the Order therefore it is permissible to have Order Line Ids such as 1, 2, 3 etc. on each order. It is, of course, valid to use a globally unique identifier on each Order Line for persistence purposes, while having a locally unique candidate key for presentation, but it is not required.
It is not permissible to have references to entities or value objects from an Aggregate Root other than the Aggregate Root itself. In a CQRS system, it is permissible, indeed required, to have read models that have data from one or more Aggregate Roots.
Aggregate root is a complex name for simple idea.
General idea
Well designed class diagram encapsulates its internals. Point through which you access this structure is called
aggregate root
.Internals of your solution may be very complicated, but user of this hierarchy will just use
root.doSomethingWhichHasBusinessMeaning()
.Example
Check this simple class hierarchy
wheel是方向盘,tire是轮胎
How do you want to ride your car? Chose better api
Option A (it just somehow works):
Option B (user has access to class inernals):
If you think that option A is better then congratulations. You get main reason behind
aggregate root
.Aggregate root encapsulates multiple classes. you can manipulate whole hierarchy only through main object.
回答4
Imagine you have a Computer entity, this entity also cannot live without its Software entity and Hardware entity. These form the
Computer
aggregate, the mini-ecosystem for the Computer portion of the domain.Aggregate Root is the mothership entity inside the aggregate (in our case
Computer
), it is a common practice to have your repository only work with the entities that are Aggregate Roots, and this entity is responsible for initializing the other entities.Consider Aggregate Root as an Entry-Point to an Aggregate.
In C# code:
Keep in mind that Hardware would likely be a ValueObject too (do not have identity on its own), consider it as an example only.
where T : IAggregateRoot
- This one made my day 通过泛型约束确保repository只会操作aggregate root, 下面是微软官方的ddd的示例DDD_Aggregate
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.
For more details see the Domain-Driven Design book
.
Aggregates and Aggregate Roots
Background
An Aggregate is an object or collection of objects (Entities and Value Objects) that must be treated as a single unit for the purposes of a business transaction. The Aggregate will maintain all invariants for all objects that comprise包含;由…组成 the Aggregate, enforcing all business rules internal to the Aggregate.
Aggregate Root
All Aggregates have a single point of entry that is know as the root. The Aggregate Root is the interface to the external world. All interaction with an Aggregate is via the Aggregate Root. As such, an Aggregate Root MUST have a globally unique identifier within the system. Other Entites that are present in the Aggregate but are not Aggregate Roots require only a locally unique identifier, that is, an Id that is unique within the Aggregate.
For example: an Order will contain Order Lines. The Order is the Aggregate Root and must have a unique Order Id. The Order Lines cannot be accessed directly. Any updates to Order Lines must be via the Order. That is, you ask the Order to make the change to ITS Order Line. An Order Line is only required to be identifiable with the Order therefore it is permissible to have Order Line Ids such as 1, 2, 3 etc. on each order. It is, of course, valid to use a globally unique identifier on each Order Line for persistence purposes, while having a locally unique candidate key for presentation, but it is not required.
It is not permissible to have references to entities or value objects from an Aggregate Root other than the Aggregate Root itself. In a CQRS system, it is permissible, indeed required, to have read models that have data from one or more Aggregate Roots.