
The Domain-Driven Design Paradox (2016) - fagnerbrack
http://ouarzy.azurewebsites.net/2016/02/17/the-ddd-paradox/
======
OpenDrapery
When the developer is the domain expert, you've achieved the singularity. /s

A large percentage of the time, there is no domain expert available, or there
simply is no domain expert. We've all worked at that place. You start a new
job and you're left to your own devices to sink or swim. You wonder why no one
can be bothered to take the time to give you the big picture. Who is the
customer? Who is the user? Are they the same person? What problems are we
trying to help them solve? Are we optimizing for speed, correctness,
usability? How do our competitors do it? Who are our competitors?

How about some backstory on this codebase? I can look through source history
like I'm doing an archaelogical dig. But how about a narrative on why certain
choices were made?

The reason no one will take the time to answer these questions for you is that
they will quickly be exposed as not having answers. The best they can do is
say "I'll have to ask so and so", and then you'll never hear back.

Also, there is a pervasive vibe that when you're brought on as a developer,
it's not your place to ask business-y type questions. Let the people person
talk to the people, and you dig ditches where we tell you to dig them. And if
we ask you to fill it back in because we told you to dig in the wrong place,
well then, you're here 40 hours a week and work is work right?

/end rant

Sorry guys, my fingers just kept typing.

~~~
wpietri
I've never worked at a place without a domain expert.

If the company's new, then everybody's aware that they're learning, and so
they actively seek expertise. If the place is old, then I've always been able
to find people who understand the domain; they've been soaking in it for
years.

What you're asking for is something a little different, somebody who can feed
you a pre-digested analysis, one suitable for understanding/designing the
code. That definitely doesn't exist. That person must be us.

We understand our domain, computers. They understand their domain, business.
They will never understand computers particularly well. So it's incumbent on
us to lead the collaboration to create a shared domain model, a formal map of
their territory.

Of course, some places do try to stop us from working in the ways that are
most effective, to treat us as robots. When that happens, the old Agile advice
applies: either change your organization or change your organization.

~~~
seanmcdirmid
> either change your organization or change your organization

Two different but related meanings coming from two valid parses of the same
string, nice!

------
coconut_crab
> Even on the implementation side of a project, there is a lot from DDD that
> is always usefull. It’s not always about CRUD or CQRS and Event Sourcing.
> But it’s always about naming the methods, classes, interfaces and modules
> according to the domain language, the Ubiquitous Language. This is DDD.

> If I encourage collaboration between technical and domain experts and work
> iteratively to refine a conceptual model, I can claim I’m doing DDD.

This. I am tired of the so-called 'DDD-experts' trying to convince us that you
must use X framework with Y techniques to 'properly' implement DDD. In the
eyes of some managers I know DDD is something mysterious, something that
requires expert consultants to do and if we copy paste their design we will be
doing 'DDD'. That explains why in my company each team has their own
understanding of 'DDD'. To me, the Ubiquitous Language is the essence of DDD.
As long as I name my class/method/function/variable accordingly then I am
doing DDD. And we try to make it so that the Domain Experts can read our code
and say its business logic is correct or not, even if they don't know anything
about programming at all. To do that we can use whatever tools/languages we
want, OOP, FP, Free Applicative, DSL etc..

It's the Domain that matters in Domain Driven Design, not the framework or
languages or even design patterns.

EDIT: Fixing formatting again..

~~~
blowski
Everybody seems to agree that when your engineers understand the domain they
are working on, they build better solutions. There is always some snake-oil
salesman suggesting your engineers either don't need to understand the domain,
or there's a shortcut by which they can learn it.

There isn't. And every generation seems to rediscover that truth and give it a
different label.

~~~
hashhash
Just to reinforce what you are saying, there were people doing this even in
ancient Greece, see Plato's Gorgias.

[http://www.gutenberg.org/ebooks/1672](http://www.gutenberg.org/ebooks/1672)

------
saycheese
Cache of page:
[http://webcache.googleusercontent.com/search?q=cache:http://...](http://webcache.googleusercontent.com/search?q=cache:http://ouarzy.azurewebsites.net/2016/02/17/the-
ddd-paradox/)

~~~
Dolores12
> Error 403 - This web app is stopped.

Oh, 2017... We need web app to show static content.

~~~
nbevans
This. We've been pushing Microsoft to add static site support to Azure Blob
Storage for years but keep getting rebuffed. Apparently their official advice
is to spin up a free "Web App" \- as if that is in any way comparable to a
truly distributed static file server like S3 / AzStorage.

~~~
numbsafari
Clearly they don't want your business. So, why not use someone like GitHub,
AWS, or GCP who does?

~~~
user5994461
Use wordpress for your content.

The clouds will charge $300 when you'll go first page on HN. You don't want
that.

~~~
abdullin
I have a counterexample.

My blog is hosted on AWS S3 with CloudFront CDN and costs a few dollars per
month (most of that comes from Route 53). One day it appeared on the front
page of HN. Total blog cost that month didn't exceed 5 USD.

~~~
user5994461
You are lucky to have a small audience and no media to deliver.

------
zapov
While I like DDD very much (created much tooling over last 10 years to help
develop software in such a way), but if you move outside of useful
implementations, you don't end up with much. Talking to domain experts,
analyzing your domain... that's just a straw man arguments to sell DDD.
Ubiquitous language is a good argument for DDD, but I don't see that practised
a lot. There is often a noticeable disconnect between how experts talk about
the system and the abstractions in the system which represent them.

Also, on technical level, while there are a lot of useful things in DDD
(aggregate roots, value objects, repositories, ...) there is also a cargo-cult
like notion what is a good way to develop software. And when you listen to
"the experts" you often get a feeling they can fake the talk, but surely don't
know how to walk.

My single question to see if someone is practicing DDD is: do you refactor
your codebase on deeper insights? I'm yet to see someone say yes to that.
Often you get excuses not to touch code which is working since refactoring
large codebase is impractical/risky.

~~~
blobman
I refactor my code fairly regularly (as specifications change). The use of
TDD, DDD, CQRS and Event Sourcing gives me immense flexibility to be able to
refactor a large codebase and then test it through its whole lifespan (with
actual data).

~~~
lpedrosa
> The use of TDD, DDD, CQRS and Event Sourcing gives me immense flexibility to
> be able to refactor a large codebase and then test it through its whole
> lifespan (with actual data).

What is your experience in applying those principles in a team? It would be
very interesting to get some insight on it.

~~~
blobman
1\. TDD is simple enough. Everyone should be doing it. 2. DDD - this usually
results in plenty of healthy debates on naming conventions. Acronyms are
abhorred and we try to agree with the stakeholders on the meaning of each word
they use. 3. CQRS and Event Sourcing - this has required our team quite a bit
more of startup time than a CRUD application would have. We have been lucky to
have a very understanding Product Owner who gives us plenty of time to deal
with tech debt. Although single features may have originally taken us longer
(than the time it would have taken to do the same with CRUD) at the start of
the project, years on this time and the complexity of refactoring or adding
features has not really increased, as any functionality is contained within
its bounded context.

The biggest difficulty has been explaining what we are doing and why to senior
management. But we haven't had any bad incidents so far, so I think they like
us.

~~~
thijsvandien
Do you do full-blown event sourcing or apply it to specific areas only? If the
latter, how do you decide which? How do you deal with performance? Specialized
database (e.g. Event Store) or not?

Real life success stories about ES are rare, so I'd love to get more insight
in the anatomy of the solution (way beyond these few questions). Blog post
request, I guess.

~~~
blobman
We have full-blown event sourcing for pretty much everything. The performance
on the read side is great (obviously). We have an Event Store and we rebuild
the Domain for every new command, so it isn't particularly fast, but we have a
situation where commands are only issued a few times every year by a single
person, whereas there are millions of reads every day (hence justifying CQRS
as a solution). We have a mixed solution around replaying events though,
largely around the issues we have with file uploads. Every file upload
triggers multiple events (uploaded, processed etc) and we have different
solutions for different files. Small files we store in the events as a blob,
whereas big file events upload the data to a projection store and will not be
replayed, so we don't have the issue of having to keep the original files
forever as well as the database. I should probably write a blog post about the
project at some point, but I'd like to investigate with my bosses as to how
much I can actually reveal about the domain (because it would make the read so
much more interesting if I could say everything).

------
blobman
Frankly, concepts like Ubiquitous language ARE definitely a silver bullet -
I've written an article on how they increase your bus factor (
[http://www.michalpaszkiewicz.co.uk/blog/busfactor/](http://www.michalpaszkiewicz.co.uk/blog/busfactor/)
)

~~~
pwm
Ubiquitous language only exists in mature domains. If you think of mathematics
as the ultimate example of clear and precise language with rigorous
definitions then most domains are on the other end of the spectrum. In these
domains there are multiple names for the same concept within a department let
alone the whole company. Changing that requires patience and continuous direct
access to stakeholders/experts. Not impossible but I have rarely seen it work
to its full potential.

~~~
blobman
You are absolutely right, but campaigning for a ubiquitous language in a
company has far more benefits than just the application of DDD to your code.
In meetings with other teams or stakeholders, we often hear or say things like
"can we agree to call _this thing_ _this_ from now on". We then proceed to
clarify exactly what is meant by the terms. It goes a long way.

------
techdominator
I don't think DDD is a silver bullet; building quality software will require
DDD but it will also require more.

But don't get me wrong, I always been a proponent of keeping Domain concerns
in The Domain layer.

It makes much more things easier in the long run, beginners should be exposed
to DDD very soon in the learning process, in my opinion.

DDD and the principle of separation of concerns always reminds of Uncle Bob
screaming "DATABASE IS DETAIL!":
[https://www.youtube.com/watch?v=o_TH-Y78tt4&t=42m45s](https://www.youtube.com/watch?v=o_TH-Y78tt4&t=42m45s)

------
davis
Do people still recommend Eric Evans' book on DDD? Or would Vaughn Vernon or
Scott Millett be better ways to learn it as of now?

~~~
numbsafari
I personally found the Vernon book to be overly repetitive and actually light
on real application guidance. It almost turned me off to DDD.

The Evans book is the better investment by far.

~~~
thijsvandien
While Millett and Tune's book is generally good, it too is very repetitive
about the fundamentals.

------
hermitdev
A bit of advice to authors: define acronyms when you first use them. DDD is
defined the link text locally, on HN, but not at the site. CQRS & CRUD are
also not defined. I'm familiar with CRUD, but not CQRS. DDD, lacking context,
I was initially thinking the graphical front-end for gdb.

~~~
hermitdev
TL;DR: There's too many T.L.A.'s pulled out of A.S.S.'s and sometimes, a bit
of context to disambiguate is helpful.

------
ninjakeyboard
Agreed. Focusing on the domain is never a bad idea. The application of DDD can
be insane though. If you have to learn about event sourcing and CQRS and
microservices architecture, and schema evolution, and scala and Akka cluster
with sharding and singletons and whatever else is employed just to be able to
function, it can be very impractical to build and grow teams, let alone run
the software.

~~~
timclark
All those things that you mentioned are just implementation details that some
people use with DDD, you can do DDD with assembly if you wanted to.

~~~
biehl
Or plain Java or C#, more likely :)

