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…
3/ Domain Queries: Replace Free Queries with Domain Queries to decouple from knowledge of the server's internals. verraes.net/2019/05/patter…
4/ Completeness Guarantee: Design the set of Domain Events from a producer so that they can be used to rebuild the producer's state.verraes.net/2019/05/patter…
5/ I'll publish more patterns as I write them. It's also part of my DDD for Messaging Architectures workshop next month in Amsterdam. training.dddeurope.com/ddd-messaging-…
6/ And there we go: Passage of Time Event
Replace cron jobs and scheduled commands, with an agnostic event to indicate the passage of time. verraes.net/2019/05/patter…
7/ Fat Event: Add redundant information to a Domain Event to reduce complexity in the consumer. verraes.net/2019/05/patter…
8/ Explicit Public Events
Mark a small subset of events as public, keep the rest private by default. verraes.net/2019/05/patter…
9/ Segregated Event Layers: Explicitly segregate a Bounded Context's events in visibility layers, with their own language. verraes.net/2019/05/patter…
10/ Eventsourcing Patterns: Forgettable Payloads. Store the sensitive payload of an event in a separate store to control access and removal. verraes.net/2019/05/events…
11/ Eventsourcing Patterns: Throw Away the Key. Encrypt sensistive information in an event and delete the key. verraes.net/2019/05/events…
13/ I renamed "Throw Away the Key" to "Crypto-Shredding", as that terms seems to be more common. Also added a bit more discussion. verraes.net/2019/05/events…
17/ You: Hey Mathias, if only we could spend 4 days in Amsterdam with a bunch of smart people to learn about many more patterns, DDD, temporal modelling, CQRS/ES, architecture,...
Me: I'm just going to drop this link here training.dddeurope.com/ddd-messaging-…
18/ Eventsourcing Patterns: Decision Tracking. Store the outcome of a decision to guard against rule changes. verraes.net/2019/05/events…
19/ Eventsourcing Patterns: Migration Events in a Ghost Context.
Explicitly conform to the legacy component's model in an eventsourcing migration. verraes.net/2019/06/events…
20/ Natural Language Message Names. Embed more meaning in messages by using verbs. verraes.net/2019/06/messag…
24/ New blog post: "Eventsourcing: State from Events or Events as State?" where I'm comparing two common interpretations of eventsourcing; and proposing a definition. verraes.net/2019/08/events…
• • •
Missing some Tweet in this thread? You can try to
force a refresh
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/
There’s evidence of the Manoeuvre being applied. GitHub for example is a distributed company that built a tool for distributed collaboration using GitHub to build it. 3/
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/
Imagine being born with a perfectly capable brain, but the way you perceive the outside world is entirely different. Not wrong, just different, and the world doesn't accommodate for how you perceive it. 3/
I consulted for a client that acted as a broker for paying copyright holders for the use of their content. To do this, they figured out who the copyright holders of a work were. 3/
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..."
For the record, please don't read that tweet as gatekeeping. By all means, write todo apps as a learning tool. Learn how to use patterns. But then go further. Think about your model. Can you find things that are hidden in if statements? Those might be indicators that...