For every like, I, a real human, will generate a less boring take (until I'm tired of it).
Jun 23, 2022 • 14 tweets • 6 min read
The interactive keynote by @al94781 and co at DDD Europe @ddd_eu 1. Questions on the screen 2. The audience debates and submits ideas in the app
Jun 9, 2022 • 48 tweets • 6 min read
The Inverse Conway Manoeuvre tells us to change our team and organisational structure to achieve the system design we want. More and more organisations reorganise based on this idea, and yet they don’t end up with the system they’d like. What are we missing? 🧵
(Before I start: threaded apps republish people's content without their consent. Instead, you can read the whole thread here: verraes.net/2022/05/conway… ) 2/
Apr 2, 2022 • 8 tweets • 2 min read
By age 2, my kid didn't speak, cried a lot, couldn't fall asleep without being held for an hour, eating was problem, in fact everything was a problem. Doctors said he'd never speak and would need special care forever. 1/
It was a "child without a manual". We put in the work to write one. At home, in kindergarten, with therapists. We tried lots of experiments. Eg I invented a ball throwing game to teach him the words yes and no that we played for weeks until it clicked. 2/
Mar 1, 2022 • 107 tweets • 14 min read
Let's talk about metaphors can help us when modelling and designing software systems, especially when the domain is tricky or highly technical. 🧵 1/
(No need to use a threader app, you can read the blog post @rebeccawb and I wrote here: verraes.net/2021/12/models… )
2/
Feb 3, 2022 • 13 tweets • 3 min read
Bloggers: "I'll demonstrate DDD by building a Todo app"
Actual DDD: "We looked at how people are using Todo lists, and we figured that our model was wrong. Besides TODO and DONE, we needed to afford for POSTPONE, WON'T DO ANYWAY, and TOO LATE. A quick experiment showed that..."
Btw here's a glorious piece of writing on DDD done well weronikalabaj.com/to-ddd-or-not-…
Sep 16, 2021 • 8 tweets • 2 min read
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.)
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
Aug 28, 2021 • 11 tweets • 2 min read
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.
Aug 27, 2021 • 27 tweets • 4 min read
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".
Jul 5, 2021 • 23 tweets • 4 min read
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
May 7, 2021 • 11 tweets • 12 min read
@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.
Apr 29, 2021 • 12 tweets • 2 min read
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/
Apr 12, 2021 • 15 tweets • 3 min read
I’m having lots of conversations with @rebeccawb about Bounded Contexts in Domain-Driven Design. This is a small snapshot of some of the tensions involved in picking good boundaries.
🧵⬇️ (1/15)
Some context:
A Bounded Context is an “understandability boundary”, a boundary around a model and its language. You can understand the model and the language in isolation, without having to understand other Bounded Contexts. (2/15)
Feb 12, 2021 • 8 tweets • 2 min read
The most important thing you can do when trying to learn Domain-Driven Design is still very much Eric's book amzn.to/3b1Uqrx People are not recommending this book enough because few have actually finished it.
It has a reputation of being hard to read, which is deserved. Read a little bit every day. Or read the bold parts first, then start over to read it thoroughly.
Feb 11, 2021 • 8 tweets • 2 min read
The larger the client, the more likely they hire me because they want to "get it right the first time and avoid rework", and the more likely they end up not hiring me because before they do, they want to agree on the scope of what I will do for them.
Repeat after me: All good design is redesign. Rework is a feature, not a bug.
Dec 29, 2019 • 7 tweets • 1 min read
"As small as possible" (DB partitions, message size, μsvcs, Bounded Contexts, class names, method arity, ...) is almost universally bad advice in software design. Some critical logic is going to cross those boundaries and result in poorly implemented, preventable workarounds.
But, "Whenever something is wrong, something is too big" (Kohr 1957) is also true for software. Big things are more obviously bad. Small things look simple, because the wrongness hides not inside the things, but in their connections.
Dec 14, 2019 • 10 tweets • 2 min read
The problem is not that you shipped on Friday. The problem is that you have no way of knowing if shipping will break it. Most software is massively undermodeled and undertested.
Models (1) and tests (2) are two sides of software success: 1) do I understand this software so well that I can accurately predict the impact of a change in the system's behaviour 2) can I delonstrate confidence in its behaviour by repeatedly testing lots of scenarios
Jul 23, 2019 • 8 tweets • 2 min read
I wish we'd stop debating OOP vs FP, and started debating individual paradigms. Immutability, encapsulation, global state, single assignment, actor model, pure functions, IO in the type system, inheritance, composition... all of these are perfectly possible in either OOP or FP.
Some are better, some are worse, some are highly dependent on context, let's figure that out instead of religuously bashing umbrella terms like OOP and FP. And there may be many more paradigms to discover.
Jun 5, 2019 • 9 tweets • 2 min read
1/9 Software design is invisible design. Its primary audience is the other designers.
2/9 Decision makers are used to design being something that produces visible outcomes: things, UIs, features, experiences. It's very hard for them to understand why they should care about software design.
May 10, 2019 • 24 tweets • 7 min read
1/ I've started publishing some Patterns for Decoupling in Distributed Systems on my blog. It's all very rough around the edges for now, I hope to improve them based on feedback.
2/ Summary Event: Instead of emitting a stream of Domain Events, emit a single Summary. verraes.net/2019/05/patter…
