CODEWITHSUNDEEP
domain-driven-designaggregateidentity
ses
ses

Reputation: 13372

Domain Driven Design and local identity in an aggregate

In Domain Driven Design there is an Aggregate Root that has reference to internal entities.

Aggregate Root is an entity with global identity (everyone able to use its id). Aggregate root has links to local objects (entities).

Assuming here that Entities are the Hibernate @Entities (let's say)

Let's say we have Aggregate Root "User" that has "Address" entity in it as an object (which is actually an entity as well)

The question is: How is it possible to make local entities to be with local identity only. I mean, there is no any barriers that could prevent anyone to use local entities (like Address) by its IDs. (so then this identity is not local at all, but global). Then, what is the way to make it local?

Upvotes: 0

Views: 1901

Answers (3)

Ibrahim Najjar
Ibrahim Najjar

Reputation: 19423

Well i don't think this is a matter of a public field or property or some access restriction mechanism, the way i see it "local identity" means that objects outside of the aggregate boundary can't use that local identity in a meaningful or useful way (e.g. they can't use that identity to retrieve that object or persist it to the database or any other operation). That identity doesn't mean anything to the outside world and it is only unique within that aggregate. Another example, what guarantees you that objects outside of an aggregate boundary won't hold references to objects within (which violates one of the principles of aggregates), well nothing unless those objects are VALUE OBJECTS which might not be the case every time. If i want to put that in a few words: Don't create any public APIs that use identities of objects within an aggregate , this way you will make it clear to the developer not to use those IDs.

Upvotes: 4

Eben Roux
Eben Roux

Reputation: 13256

Entities within an aggregate root are supposed to only have local identity. For all intents and purposes the database table need not have a primary key. When the aggregate is hydrated the entities within the AR should be fetched based on their link to the AR. But even that FK need not be represented in the local entity since the connection is obvious based on the containment of the local entities with the AR.

Since most database systems will moan if there is no PK on a table so you could add one for the sake thereof but you can just ignore it in your entity design. So there would be no property for the PK in the entity. The only way someone could then get to that entity is by way of the DB since there should be no way in your code to do so.

Upvotes: 2

eulerfx
eulerfx

Reputation: 37739

All entities, including the root, have an identity. The fact that only the identity of the aggregate root should be used "globally" is something that cannot be easily enforced by the code itself. In a relational database in particular, every table record will have some key, regardless of whether that record stores an aggregate root, and entity or a value object. As such, it is up to the developer to discern which database identities are part of the domain and which are not.

Upvotes: 3

Related Questions