oop - Domain Driven Design - Creating general purpose entities vs. Context specific Entities -


situation

suppose have orders , clients entities in application. in 1 aggregate, order entity considered root want make use of client entity simple things. in client root entity , order entity touched ever lightly.

an example:

let's in order aggregate use client read details name, address, build order history , not make client client specific business logic. (like persistence, passwords resets , flips..).

on other hand, in client aggregate use order entity report on client's buying habbits, order totals, order counting, without requiring advanced order functionality order processing, updating, status changes, etc.

possible solution

i believe better solution create entities each aggregate specific aggregate context, because making them full featured (general purpose) , ready situation , usage seems overkill , potentially become maintenance nightmare. (and potentially memory intensive)

question

what ddd recommended way of handling situation? take on matter?

the basic driver these decisions should ubiquitous language, , consequently real world domain you're modeling. if both works in specific domain, i'd favor separation on god-classes maintainability reasons.

apart separating behavior different aggregates, should take care don't mix different bounded contexts. depending on requirements of domain, make sense separate purchase context reporting context (to extend on example).

to decide on context design, context maps helpful tool.


Comments

Popular posts from this blog

c++ - llvm function pass ReplaceInstWithInst malloc -

java.lang.NoClassDefFoundError When Creating New Android Project -

Decoding a Python 2 `tempfile` with python-future -