Hacker News Reader

Comment by seanwilson | Hacker News Reader

> Software for a complex domain requires all designers (engineers, testers, analysts, …) to have a deep, shared understanding of the domain, guided by domain experts ... That understanding is rooted in language: the domain language should be formalised into a Ubiquitous Language (shared, agreed upon, unambiguous) ...

> DDD is not prescriptive. It doesn’t have rules of how to do it, and is open to new interpretation. It doesn’t prescribe methods, or practices, and even the patterns in the book1 are meant to be illustrative rather than a final set. ...

> That makes DDD notoriously hard to define.

I don't know anything about DDD, but if you can't concretely describe it and how it's different to how teams naturally work together, how can it be actionable and what stops it becoming another cargo cult when nobody can agree on what it is?

View on HN

The book that introduced the term, “Domain-Driven Design” by Eric Evans, is thick but excellent.

I recently came across this talk from Scott Wlaschin titled "Domain Modeling Made Functional".

I found it a great practical introduction to DDD.

https://www.youtube.com/watch?v=PLFl95c-IiU

If that talk speaks to you (as it where) I can also highly recommend his book with the same title, https://pragprog.com/titles/swdddf/domain-modeling-made-func...

They are the probably the best concrete and actionable introductions to DDD out there, and do a very good job of separating practical DDD from the OOP dogma that it is sometimes tied to. The book uses F# as it's language to implement and demonstrate its examples, but most of the concepts are presented in a language agnostic way.

I find it hard to understand how you'd get the essence of the idea from some of these descriptions, I was lucky enough to be at OOPSLA when Erics book came out and he had a session on it, I think he explained it pretty well, not sure if there are online presentations of his that are good, his book is good, but has a lot of extra more "technical" stuff to deal with how to implement it.

Agreed, my issue wity DDD is that it is based on a bunch of good ideas but very little of it is actually actionable.

I actually think that this perception is what has caused most of the architectural overkill mentioned in this thread. People want something "actionable", so they extract the specific patterns.

The most important part of DDD is the principles. It's a way of looking at the world and at problems, of seeing things first and foremost from the business perspective. How you apply those principles to achieve that perspective must vary dramatically from project to project, which means that the details of action are left to you to decide.

Several of the ideas, like ubiquitous language and bounded contexts, are highly actionable.

DDD always felt like a bad adaptation of the emperor's clothes for programmers to me.

Reply on news.ycombinator.com