CODEWITHSUNDEEP
design-patternspersistencedomain-driven-design
Leonardo
Leonardo

Reputation: 11387

Points that are allowed to interfere in the domain design

When design a domain in DDD, Evans preach that things like the data store should not influence the entities behavior/fields, yet he advices agains "deep" object graphs (a.k.a crossing). I think that deep down, his subconsciousness is yelling something like "too many joins" or maybe "too many data over the wire"... so my question is: What other factors are allowed to shape my design?!?

Upvotes: 0

Views: 40

Answers (2)

MikeSW
MikeSW

Reputation: 16348

It's just proper modelling and YAGNI at play. You design objects according to proper business concepts. And very often, for example, an Agregate Root isn't that big because in the end it's just a concept with some behaviour. But a lot of people consider it a container and put everything in there. A domain model usually consists from many smaller objects, instead of godzillas .

You want clean, decoupled code. Deep objects graphs = complexity. Why complicate your life? SRP is quite important here and quite often mammouth classes are a sign of wrong modelling.

And as an answer to your question, only the Domain should be allowed to shape the design because you know... Domain Driven Design.

Upvotes: 1

Christian Bongiorno
Christian Bongiorno

Reputation: 5648

This question, while 'good' in nature, is far too broad and opinion based.

You are allowed to have anything motivate your design.

As for 'too deep' of an object graph, it directly gets to targeted data queries. If you have a deep graph there will be a nasty propensity to pull in far too much data, that you will then throw away when you trim it down for a dto/webservice.

Upvotes: 1

Related Questions