Share this page!

Mathias Verraes Profile picture
Twitter logo
16 Sep, 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.)

• • •

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

Mathias Verraes Profile picture
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
Mathias Verraes Profile picture
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
Mathias Verraes Profile picture
27 Aug
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.)
Read 27 tweets
Mathias Verraes Profile picture
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
Mathias Verraes Profile picture
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
Mathias Verraes Profile picture
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!

Like this author's thread?

Get emails when @mathiasverraes has new unrolls!

Check out other threads from @mathiasverraes!

Read all threads by @mathiasverraes

:(