Two main rules to Domain Driven Design:
- do not share models (and data)
- keep your business logic away from view and infrastructure
Do not share models
It is better to repeat yourself than end up in complicated inheritance with switches.
It is ok for human being take different hats depending on the context, but not for the same human being debugging complicated business logic squeezed into the one model body.
How you smell it? Your functions have multiple core streams. You feel one test cannot cover same function.
It is not bad to have multiple customer classes in different contexts. Customer in search, in recommendations, in shopping card, in checkout, in shipping and in billing are different. In some cases those contexts do not overlap but when they do trouble starts.
Keep our business logic safe
If you want to be flexible on choosing technology and migrating from one to another quickly keep business logic in separate space 3qlwrwd.
DDD people suggest having infrastructure and view layer but there are different ways to achieve this. Most important is to keep it away from especially persistence layer, as that is what often happening . This is hard to reach if you do not repeat yourself – see point above. When your model is complicated you have complicated ways to retrieve data and you end up coupling business logic with persistence layer. Simplest models can be easily stored even in files as JSON files.