Search code examples
domain-driven-designmodelinganemic-domain-model

Effort to enhance


The question is from the from the patterns of enterprise application architecture by Fowler.

My effort to enhance formula = d x r + c

  • d number domain definitions(classes)
  • r replication of definitions
  • c complexity constant

But having a hard time about justifying it for the table module pattern growing exponentially as there is not much replication of definitions at that part.

Why does table module effort to enhance grow exponentially ?

enter image description here

References


Solution

  • Well, it's favourite diagram of Dino Esposito :o)

    Mostly it's based on developer's experience and feelings. As for me, Domain Model is applicable for not many systems, for most of them less complicated patterns should be used. May be, it's you case. Well-designd table module application can have "liner" complexity for many and many years and this is ok. But if you feel, that you spend much time on doing the same job for different parts/classes/modules of your application, if you feel, you can't control it, if you have distributed team and 10-20 developers, you can think about separation of concerns, bounded context and domain model. So, this diagram is mostly marketing step to "sell" you DDD. I like DDD, but it really takes a lot of time at the beginning and there is a chance, that you never reach time, when DDD will be easier than any non DDD-way.

    So, answering your question - no reason, just to tell that sometimes DDD is better.