Domain-Driven Design, part 3 — Simplify Object Model

Model

It doesn’t make sense to explain modeling on Foo, Bar, etc…, the Domain-driven design is about the domain. Let’s use an e-shop cart model from the previous article.

Concrete Associations

Associations between objects are naturally two-ways. But it’s really difficult to think, work and program with two-ways associations. We try to simplify them if it’s possible.

Entities

Who am I? I’m a unique person. I can cut my hair, change a name if I marry, or have an accident and my body shape might change. My look might change, people might call me differently, but it is still me. It is my identity what identifies me, nothing else.

Identity

An entity is identified by an identity. This has some practical consequences. A unique entity must be only one in the system, stored as one piece of memory. When we compare entities, we have to compare only their identities. If the identity is same, the entity is same.

Cart Entities

A cart — if we add a product, is it still the same cart? It is. Entity.

Value Objects

We have to paint a room, what do we need? A paint of a given color. While we are painting we do not care which drop of paint is where, as long as we have enough paint we are able to finish the job. And if we spill a can, we can replace it with a new one without noticing a difference.

Identity and identifier

Entities are identified by an identity. How do we select an entity from a collection? We need a tool which also identifies entity, and that tool can be an identifier.

Cart Value Objects

The price is a typical value object in a cart model. It represents how much does the item cost and is identified by its value.

Aggregates

An aggregate is a group of objects that live and die together. Aggregate parts do not make sense without each other, they make sense only if they are all together.

Cart Aggregates

A product is a thing in which are our customers interested in. We would just say it is an aggregate.

Separated aggregates

Aggregates must be understood whole or not be understood at all, must be created wholly or not be created at all, must be persisted whole or not be persisted at all, must be received from a repository (database or any storage) whole or not be received at all.

Benefits

  • Easy to understand
  • Easy to test
  • Easy to persist

Problems

What about the data integrity? What happens if we delete a product? It doesn’t have to be a problem — we don’t have a delete use case, so in this system, it cannot happen.

TL;DR

The model can be simplified by concreting associations, identifying entities, value objects, and aggregates. Aggregates can be separated to be easy to understand, implement and test.

References

EVANS, Eric. Domain-driven design: tackling complexity in the heart of software. Boston: Addison-Wesley, 2004. ISBN 0–321–12521–5.

Contact

Are you designing architecture and like DDD approach? Hire me, I can help you — svatasimara.cz

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Svaťa Šimara

Svaťa Šimara

Developer interested in Domain-Driven Design & Modeling