The previous episode in the series (part 2) can be found here.

What was supposed to be a single, short blog post has grown to a series of at least four articles (because this one is not the grand finale yet). The good thing is that it was the readers' feedback that drove that change - apparently, the topic is vital for many as it has sparked a lot of good discussion already.

Part 3 (the one you're reading now) is supposed to address just one (and only one) of the most interesting comments I've read (paraphrased for the sake of brevity) under prior posts:

"If DDD didn't fulfill its promise, why are there many companies that claim to have succeeded with it?"

It's a good question that deserves to be tackled in a thoughtful, structured way:

1. Are there really many companies claiming that?
2. Who are these companies - do they have something in common? Are there any regularities to be spotted here?
3. How did these companies define "success"?
4. What about the time spectrum? Did DDD unlock them ("unclog") temporarily, or was the effect persistent?

Let's pause here for a second. Like all the previous posts in the series, this one is based on my experience (23 years in the industry, 12 years since I got familiar with DDD) and opinions. To be clear, I have not conducted a scientific study on a large number of companies - it's only a generalization of my own observations and anecdotal evidence I've encountered throughout my career. If you have counter-examples that lead to different conclusions, I'll be happy to read them. The comment section below is open.

OK, back to our consideration then.

Yes, you can find successful case studies of "applying DDD" (online). I wouldn't say there are tons of them, but enough to get them together and "segment" them into groups that share some similarities.

Types of success

Here are four types of "DDD successes" I've seen most frequently:

1. Event-junkies, AKA yet another Event-sourcing implementation. Originated by a technology enthusiast (or a couple of them) fascinated by the aesthetic cleverness of turning everything into an event (because it's so much better than turning everything into a class ...). These ("successes") are usually documented just after implementing the first couple of event types, not years after - I wonder why ...
2. EventStorming "wow effect". This is a testimonial of a successful ES session: some folks are genuinely amazed by how much they've learned (about their domain and that other folks don't bite) during a single workshop (no sarcasm here, btw).
3. New broom. There was a new opening in the software workshop (e.g., new architect/CTO), and now they are chaotically trying to improve stuff here and there by adopting random elements of XP, Clean Code/Architecture, DDD, Agile/Kanban, DevOps, ... - mostly vocabulary and meaningless details, but even that brings a lot of good energy (& hope for future) to the team.
4. Consulting commando. A pack of consultants is brought in to save the (more or less) burning platform (e.g., monolith entangled beyond all recognition). They attack the problem(s) with a lot of energy, mine (domain) knowledge, utilize tons of colorful post-it stickers, use a lot of DDD lingo, shift & stretch, and in the end, come up with a "to-be" blueprint & bag of (typically re-used) conventions. Sometimes, they also attach a draft of a transformation project (how to get from "as-is" to "to-be").

Let's take a look at each of these separately.

How much success in "success"?

I don't know about you, but I think the first group ("Event-junkies") has very little in common with DDD and is most likely not a success at all. Event sourcing is a handy pattern if applied reasonably within a proper scope. Treating everything as an event is utterly crazy - it adds yet another layer of abstraction (more complexity) and makes everything asynchronous (even more complexity ...). This is sabotage, not solving problems (of excessive complexity). Btw, it's one of the practical reasons why the actor model has failed as a foundational architecture concept (for whole systems/apps).

Group two ("EventStorming wow effect") is definitely a success. But, it's the success of a particular workshop technique (ES), not the DDD itself. It's one wrench, not a complete toolbox.

I'm eager to risk the statement that group three ("New broom") is the most common. Sadly, it's not about DDD at all. It's a more or less conscious manipulation: a new leader needs a quick buy-in and a handful of attention-catching labels to make their way more appealing. So they "practice DDD" by introducing the "DomainEntity" class and inheriting from it. Or something equivalently fruitless. But at least morale is up & people can add "using DDD" to their CVs.

Cherry on the top

Last but not least, definitely the most interesting group (the fourth one): "Consulting commando". This one deserves far more space than a short paragraph, if only because, in many cases, there's actual success achieved. Here's how it typically looks alike:

A desperate organization struggles with its legacy: lost knowledge (due to attrition, lack of documentation, poor quality code), dependencies tangled beyond all recognition, inconsistent architecture visions partially implemented by people who have already left or given up, lack of internal consensus, conflicting ideas w/o necessary buy-in, etc.

Fortunately, there's a will (& capacity, & budget, & top-level approval) to invest in fixing the "debt" (they most likely call it "technical", but in fact it's probably more "model" or "organizational" debt). However, no one within the organization has sufficient credibility, authority, charisma, energy, or a compelling vision to make the necessary changes happen. They have to reach out for external help, so that's what they do.

The most precise description of the expertise they are looking for would be "Application Modernization" (AM). Sadly, AM is much less scientific discipline than we'd all like it to be: you never know what kind of "gems" you'll find in the brownfield ... That's why AM consultants rely mostly on their past experience (they've seen a lot of manure ...) & the professional intuition they've developed.

Unfortunately, "intuition", "instincts", or "gut feeling" do not sound particularly convincing when you're trying to make someone hire you. What helps is recognized methods, standards, and widely familiar acronyms - they make you more "predictable" & less risky.

"Ahhh, he belongs to the church of DDD? So it's not his own utterly crazy proprietary method that no one else knows/approves? Good, bring him in."

"DDD" works here as an umbrella term, a credential label, a psychological lockpick. The fact that particular techniques are highly individual is not a problem - their authors refer to them as "heuristics" (dangerously extending the definition of heuristic). It's exactly the same case as it was for Scrum & agile - even folks who had no intention of using canonical Scrum used its name as a door opener because it made things so much easier. The phrase "we're doing DDD" means you'll have much less to explain ("It's all like it was stated in the Blue Book ..."), even if what you use from DDD is a few basic principles (& the rest is pure "headology" aka common sense).

AM == DDD ???

But maybe this is the actual DDD? Paper-thin "branding" (10%) & individual heuristics (90%) that sometimes refer to the dictionary of common terms? Here are my issues with such AM consulting gigs:

1. They are about fixing the current version of the solution (e.g., re-organizing the code, splitting the application), not changing the way the solution will keep being developed in the future. Even optimal advice may become outdated next week (when conditions change).
2. They rarely lead to creating (or reverse engineering) the actual model (outside of modelers' heads, where they are ephemeral).
3. You can't carry on the same way (when consultants are gone), as the method is not standardized (it was their instincts & experience, not yours). You see how they've structured the solution (on paper), and you like it, but will you be able to do some more structuring (the same way) when you add new functionality/whole modules?

Don't get me wrong - AM expertise is needed (& valuable). There's definitely a (large) market for AM consulting. My problem is all about labeling AM with DDD - in many cases, it's just a sales trick. DDD is too incomplete to be treated as an end-to-end AM "method". What is more, AM typically does NOT solve (long-term) problems DDD promised to solve (F1-F2, F3-F4).

Success list: who's missing?

If you take a look at the four "success" categories I've proposed above, don't you feel there's someone missing? Who would you like to see there (to convince you that DDD is effective and does its job)?

First of all, why are there no companies associated with unprecedented success? The ones who have done exceptionally well when it comes to building software products that solve real problems? Why no hyperscalers? No unicorn scale-ups? They (re-)invent whole industries, create new business models, operate in high uncertainty conditions, and grow very quickly - they have to deal with rising complexity for sure. Why do they never mention DDD (as a tool that was essential to their success?

Why the only people who mention DDD are tech folks - consultants or those from organizations with very fossilized (intentionally or not) borderlines between business & engineering? Why are there no product folks who advocate for DDD (speak about it, write about it, share success stories related to it)? Why is it absent in all the product management/development literature - Cagan, Perri, "Lean" series, Fadell, and others?

We're almost there. The fourth (& final) episode in the series is here.