3

From a post I read it seems that Entity is just a subset of Aggregate. I've read about the two patterns in both Domain-Driven Design and Implementing Domain-Driven Design, and I'm trying to understand the UML difference between them.

Let's consider a simple class. It's a Letter holding a message, a receiver, and possibly the sender.

enter image description here

I guess this Letter class would be considered an Entity?

Now let's say we want to expand our parcel business to be able to send also Packages, then it could look like the following.

enter image description here

Since all the Items in the Package will be lost if the whole Package is lost, we use a UML Composition relation (a filled diamond). We also want to preserve the Package's consistency by prohibiting Items from being changed or removed from outside the Package. The description of Aggregate reads

The aggregate root guarantees the consistency of changes being made within the aggregate by forbidding external objects from holding references to its members.

We therefore make sure the Composition relation is hidden, and with preserved invariants, within the Aggregate.

My question is:
Can we say that the UML difference between Entity and Aggregate is that Entity does not contain any Composition relation whereas Aggregate contains at least one Composition relation?

Community
  • 1
  • 1
Daniel
  • 73
  • 6
  • "entity" is a UML keyword, having pretty much the same meaning as it has in a general IT context. It is a predefined standard stereotype applied to a Component. The Semantics in the UML doc are given as "standard stereotype:L2 (business concept)". (L2 just means compliance level 2; UML system profiles have 3 compliance levels.) – BobRodes Apr 08 '15 at 05:26
  • 1
    p. s. Unless you want to make it possible to send an empty package, your multiplicity value for Item should be 1..*. Also, your sender should just be 1, since you don't have zero to any number of senders. – BobRodes Apr 08 '15 at 05:27
  • @BobRodes Good point. I added the relations from the perspective about what information was needed in the Package, not the perspective how it was executed. – Daniel Apr 08 '15 at 11:06
  • @BobRodes the 0..* multiplicity for Item is correct as originally drawn is correct. A Package can exist in memory or in a scenario, with no Items. That a Package cannot ship with no Items is a Business Rule. – aryeh Aug 11 '15 at 05:34
  • All right then, if you have inside knowledge of the business rules in the problem domain. I wouldn't set up the business rules that way myself. My rule would be that a package can't exist in the system without items. – BobRodes Aug 15 '15 at 02:32

3 Answers3

2

To answer your question, no you can't say that. An aggregate root is entity itself, and may or may not be composed of child entities. The child entities can also be composed of other entities as well (though not recommended usually).

The aggregate root is responsible for maintaining the state and enforcing the invariants of both itself and it's child entities.

So to recap, an aggregate and a child entity can each have 0 or more child entities. All child entities require an aggregate root however.

Tyler Day
  • 1,690
  • 12
  • 12
  • You're correct. An Aggregate Root works similar to an Entity in that it doesn't need to have any Composition relation. However, as far as I understand, child Entities do not *require* an Aggregate Root. At least if you look at Evans, p.94, Figure 5.5. – Daniel Apr 08 '15 at 10:58
  • Are you talking about when a child entity is composed of additional child entities? While the sub child entities may not directly be associated with the aggregate, they are still ultimately part of and controlled by an aggregate root. If you are saying that child entities can exist completely outside of an aggregate root, that I have not heard of. – Tyler Day Apr 08 '15 at 14:38
  • Ok, does it work like this? [Aggregate Root](http://stackoverflow.com/questions/1958621) is the only object that the client gets in contact with. Aggregate is not an object in itself but rather a [concept](http://www.sapiensworks.com/blog/post/2012/04/18/DDD-Aggregates-And-Aggregates-Root-Explained.aspx) where Aggregate = 1 Aggregate Root + N Entities + N Value Objects. Entities are never used directly by a client since they're very exposed and not under invariant protection. Instead Entities work as building blocks when building Aggregates, where the Aggregate Root preserves all invariants. – Daniel Apr 08 '15 at 19:54
  • Close, but the aggregate root is also an entity itself. For example, you could have an AR called Customer with no child entities at all. So one aggregate root can have zero or more child entities / value objects. – Tyler Day Apr 08 '15 at 20:04
1

An Entity represents the M(odel) in MVC. It's usually denoted as a <<entity>> stereotyped class.

An Aggregate is a synonym for a class which aggregates different other classes. That means it needs the other classes for its life time. There's also a Composite which is similar except that the related class instances will die along with the composite class.

To answer your final question: an Entity is atomar. It does not aggregate anything.

Edit Since I just encountered it for my work: There are Entities which compose/aggregate other entities. 30 years ago at university we called them trapeze for they hang between two other entities and relate them. Nowadays I'd call them association class.

qwerty_so
  • 35,448
  • 8
  • 62
  • 86
  • 2
    See also [uml-diagrams.org: Class Diagrams → Class → Nonstandard Class Stereotypes → «Entity»](http://www.uml-diagrams.org/class-diagrams.html#entity). From my point of view, entity is the thing which gets it's own database table. All the rest like it's relationships and it's attributes are another level of concern – xmojmr Apr 08 '15 at 03:46
  • Yes, that's what I would confirm. An Entity finally results in a database table. – qwerty_so Apr 08 '15 at 08:38
  • Thanks for your input! I guess your answer is strictly UML based. As far as I understand there's no Composite pattern in DDD. That's what I'm trying to sort out; how the DDD patterns relate to UML. – Daniel Apr 08 '15 at 11:10
  • It took a moment to figure out what DDD meant. Yes, my answer is based on UML. I don't know the book but guess it also foots on UML? – qwerty_so Apr 08 '15 at 12:40
0

An Entity in Domain-Driven-Design (DDD) is just a class stereotype in UML terms. That stereotype indicates to you that the object is identified by an explicit unique identifier, rather than its attributes.

Objects in an object model collaborate together. Together they form object graphs. An Aggregate represents a group of objects that need to be considered together because not doing so would potentially leave one or more of the objects in an invalid state.

"Can we say that the UML difference between Entity and Aggregate is that Entity does not contain any Composition relation whereas Aggregate contains at least one Composition relation?"

No. A UML composition or aggregation association is unrelated to the concept of DDD Aggregate or Entity.

For example, one can represent a Transaction-LineItem relationship in UML without composition or (UML) aggregation.

Transaction --- 1 -------- 0..* --- LineItem

Both these objects as modeled above would need to be part of the same (DDD) Aggregate because they need to be treated as a pair. If mistreated individually, one could make their combined states invalid or incorrect.

aryeh
  • 959
  • 6
  • 16