Domain-Driven Design

258 readers

2 users here now

"Domain-Driven Design is an approach to software development that centers the development on programming a domain model that has a rich understanding of the processes and rules of a domain. The name comes from a 2003 book by Eric Evans that describes the approach through a catalog of patterns. Since then a community of practitioners have further developed the ideas, spawning various other books and training courses. The approach is particularly suited to complex domains, where a lot of often-messy logic needs to be organized." -- Martin Fowler (link)

Rules

Follow programming.dev rules
Be excellent to each other, no hostility towards users for any reason
No spam of tools/companies/advertisements. It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.

founded 2 years ago

MODERATORS

snowe

canpolat

Discussion: worst experience with domain-driven design? (self.ddd)

submitted 1 year ago by lysdexic to c/ddd

2 comments fedilink hide all child comments

Anyone preaches the virtues and advantages of domain-driven design, its positive impact on maintainability and adding features, and how it improves developer experience. However, as all things in life, all roses have their thorns.

Has anyone had any negative experience caused directly or indirectly by domain-driven design? This might be a botched migration, problems during the requirements gathering stage, domain models ending up being too rigid/too permissive for an application, etc.

you are viewing a single comment's thread
view the rest of the comments

[–] lysdexic 1 points 1 year ago

Yes, I have had lots of pain from DDD. However, following the principals of pain driven development, when that pain arises we reflect, and then change our approach to reduce or eliminate that pain.

I was hoping that this discussion would lead to people sharing their personal experience to allow others to benefit from that reflection.