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 -^
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

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Mathias Verraes

Mathias Verraes Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @mathiasverraes

16 Sep
Reposting this thread about the coffee room conversations where the software design conversations happen. (The thread's order was a little messed up, and I want to be easy to find.)
Read 8 tweets
14 Sep
There is a fallacy about how domain modelling works, and we need to talk about it. With software design, you're not just solving problems, you can reframe the problem itself. 🧵 /1
(No need to use a threading app, you can also read the whole article @rebeccawb & I wrote here: verraes.net/2021/09/design… ) /2
The fallacy about domain modelling is that we can design software by discovering all the relevant concepts in the domain, turn them into concepts in our design, add some behaviours, and voilà, we’ve solved our problem. /3
Read 61 tweets
28 Aug
I should probably clarify this one before people start calling me names :-)
I probably used the term monolith a bit liberally there. But imagine you have a large chunk of your system that is very complex, because it has to deal with something with a lot of variability, in this case, different ways of doing things in different countries.
Naive strategic design here is to separate by domain (billing, invoicing, debt collection). But Bounded Contexts don't need to align with subdomains. That separation is still complex because each context needs to know country-specific things.
Read 11 tweets
5 Jul
I'm reviewing submissions for a conference I'm somewhat involved it, so here's some advice. 1/n
If the number of years you've been a programmer really is the most interesting fact about you, then by all means, open your bio with that. For everybody else, make your bio about the good stuff. 2/n
"X can be challenging. In this talk, we'll look at some [techniques|patterns|approaches] to deal with X." -> Tells us something about those approaches, because if you don't, it's hard to evaluate if it's going to be worth watching. 3/n
Read 23 tweets
7 May
@stijnvnh @cesardelatorre @yreynhout @Indu_alagarsamy I think the naming is sloppy and creates a false dichotomy. (I imagine it exists for historic reasons). The naming suggests that integration events somehow are not messages that convey something has happened in the domain.
@stijnvnh @cesardelatorre @yreynhout @Indu_alagarsamy It also suggests that events (wether persisted or not) should not leave the Bounded Context, and instead different events should be created.
@stijnvnh @cesardelatorre @yreynhout @Indu_alagarsamy I agree with the reasoning behind that, but I think the conclusion that people usually draw ("Never share domain events") is unnuanced and doesn't consider other forces. In other words, whether or not to share domain events should be a deliberate tradeoff.
Read 11 tweets
29 Apr
The right time to fix it, is right before the cost of fixing it becomes exponential. 1/
If the thing works and you don't have to add anything, don't improve it.
If you add something, and the addition of N raises the cost of improving it with N, be on high alert. 2/
If you add something and the cost raises with 2N, first improve the system to get that particular impact down to N.
If you add something of N and the cost of improving raises with N², stop the work and do system-wide improvements first. 3/
Read 12 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!

:(