Thread by @mathiasverraes

This nonsense that tactical #DDDesign isn't important has to stop. It's not even an actual opinion anyone has given proper thought, it's just a fashionable meme people are parroting. None of your strategic design matters if nobody in your org can properly implement it.

If you think tactics don't matter, you might as well wear a t-shirt saying "Ivory tower architect 4 life".

(Yes I deliberately deployed one overused meme to battle the use of another, I'm a sly fox.)

(Responses are spread across the twitters but I4ll try to capture some here:)

Broad, handwavy advice like "First do strategy before you do tactics" fits in this category as well. It makes DDD look like some voodoo that only the initiated can understand.

It's not like strategy stops when you start coding. That's not how good software design works.

The DDD community seems to define tactical design as "using a handful of programming patterns" and strategic design as either "group stuff by subdomain" or "everything that we like that is not programming".

How is modelling not tactical? How is "I'll draw this on a piece of paper real quick" or "I'll mobilize the whole team to whiteboard this" not a tactical choice?

Sometimes I use eventstorming, sometimes I use UML(--ish), sometimes I write some tests first, sometimes I spike some code first. That's all tactical.

It's also the day the day work of asking "Is this concept clear? Does this belong here? Should I go ask someone? Should I build it first and then demo it? Is this worth finding all the edge cases for?"

It's also about being aware and observant of problems in your model and your design. "This doesn't feel right, what are my options?"

And it's creating shared, understandable domain models, and having it reflected in code. And understanding patterns, whether it's from DDD or the hundreds or thousands of patterns out there, helps seeing structure and eases communication.

You're not "doing the patterns". The patterns are there, and seeing that they are patterns is useful to lighten cognitive load.

(Side point: you're completely underusing the patterns from DDD, trust me on this. Even your business rules can be value objects or entities, and you can have repositories of business rules, and you can have repositories of repositories, but that's for another time.)

Software design is messy, and can rarely be done well through append-only. Try it, observe it, have the guts to overdesign and then remove the overdesigned bits again, until it gets good enough that the design is flexible in the places where it matters.

Strategy is knowing when it matters to invest in design and when not. Strategic design is enabling that. How?

If you have a billing system that is very complex, because there's price agreements with clients, special discounts, different markets etc, a good strategy is making sure you have a good model that you can adapt fast to changing conditions.

But this model might be weighed down by a lot of other hard to change stuff, eg the invoicing and debt collection and product catalog. Strategy is figuring out if and how this could be separated.

Should you pull billing out of the whole thing? Should you pull out invoicing first to make the rest easier?

Or maybe, after trying a few experiments and being observant of the pain points, you discover that the whole way of looking at the problem is wrong: perhaps billing is actually pricing and bill calculation, and if I separate that, things get easier.

Or maybe we should DUPLICATE THE WHOLE MONOLITH FOR EACH DIFFERENT COUNTRY, start with the highest ROI one, clean it up, get rid of everything that doesn't matter, extract libraries, learn the lessons, apply to the next country.

Real world example -^

Similar example: verraes.net/2021/06/split-…

In the DDD book, Eric Evans describes some patterns that he saw for reasoning about the relationships between models. It was never intended as some kind of checklist of things to do before coding. And it wasn't an exhaustive list.

You can add "Duplicate the monolith" to your pattern backpack now (and make lots of enemies when you suggest it 🤣)

I don't really have deeper point. Let's not be handwavy about what DDD is. It's a way to think about software design, a design discipline with a focus on modelling, and getting domain knowledge and language all the way from experts to code and back, making complexity manageable.

It's not prescriptive, but it's a discipline in the sense of "we believe that if you focus more on these activities, you'll get more of the benefits". /fin