Mathias Verraes

I was a guest in Karol Skrzymowski’s podcast “Loosely Coupled”, together with Martin Fowler, Xin Yao, and Andrew Harmel-Law.

Summary Code quality is likely still important, but is automatable.

Here’s a myth that won’t die: your Bounded Contexts should map 1 on 1 to your business domains.

I wrote this joke exactly 10 years ago: There are only two hard problems in distributed systems: 2.

I’ve reviewed conference talk submissions for 10 years, for Domain-Driven Design Europe and other events.

Here’s roughly how I fixed bugs early on in my career: Browse around in the code.

There’s a moment where it’s too soon to invest in a radical new software design for your system.

Design choices carry along the worldviews of the designer.

Below are the common patterns I use when writing tests for an EventSourced application.

On the DevJourney podcast, Tim Bourguignon asked me to talk about my career.

I was at Full Stack Europe 2022 in Antwerp, and one of the speakers had to cancel.

The new DDD Australia user group just had its first meetup, and I was invited to speak.

Software Captains is a organisation that helps startup CTOs through coaching, advice, and networking.

Here’s the video of Rebecca Wirfs-Brock & my keynote at Domain-Driven Design Europe 2022, where we talk about the ideas presented in our essay “Critically Engaging with Models”, also available as an e-book on Leanpub.

Rebecca Wirfs-Brock and I published a book last year called “Design & Reality” with essays on software design.

Contents Models Are Worldviews Hierarchies and Networks Heuristics Models Distract The Spotify Model Agile Fluency Team Topologies Explicit Building Blocks When the Team Gets Too Big: a Case Study Contrasting Spotify and Team Topologies Comparing Models Y…

The Inverse Conway Manoeuvre is an organisational engineering device.

I joined Alex Bolboacă on his podcast ‘Think.

Multi-temporal Events Within a Domain Event, use separate timestamps to distinguish when the event occurred and when it was captured.

In this talk, I discuss the ideas previously presented in the articles “Design and Reality” and “Models and Metaphors” Abstract: Our models should be driven by the domain, but not constrained by what domain experts tell us.

When we make decisions, we often do not explore options that have a risk of loss, even if that loss is balanced out by potential gains.

One of us (Mathias) consulted for a client that acted as a broker for paying copyright holders for the use of their content.

I had a conversation with Ryan Shriver of Singlestone Consulting — well, mostly a monologue, I didn’t warn Ryan that he should interrupt me more :-S We talked about about DDD, boundaries, legacy, and a little bit about Shostakovich’ 15 string quartets.

Domain-Driven Design is a software design discipline centred on the principles that: Software for a complex domain requires all designers (engineers, testers, analysts, …) to have a deep, shared understanding of the domain, guided by domain experts That u…

“The transition to a really deep model is a profound shift in your thinking and demands a major change to the design.” — Domain-Driven Design, Eric Evans There is a fallacy about how domain modelling works.

Imagine a wholesaler of parts for agricultural machines.

There’s a common bias in the tech industry, and I imagine everywhere.

All models are wrong but simple models are more wrong than complex ones.

(This is a small snapshot from a longer conversation I’m having with Rebecca Wirfs-Brock about Bounded Contexts.

Decision-making heuristics are patterns and ideas that can help us find another angle, generate new options, evaluate them, or otherwise address the problem.

“Technical debt” is a metaphor for all software design choices that turn out to be suboptimal, no longer valid, or just plain wrong.

Trying to get people to agree on a single unambiguous definition of a software concept is usually impossible.

I wrote about something that I called the Forgettable Payload pattern.

This article was first published in the book Domain-Driven Design: The First 15 Years.

The versions of this talk are all part overlapping, part different.

Problem Our industry has a tradition of unnatural, compact, lossy naming.

Explicitly conform to the legacy component’s model in an eventsourcing migration.

Decision Tracking Store the outcome of a decision to guard against rule changes.

Change Detection Events Listen to a stream of events and produce a new event when a value changes.

Ephemeral Events An event’s lifetime lasts until the next event.

Throttling Only keep one event per time unit from a high frequency stream.

My aim is to identify, name, and document patterns, that I’ve used or encountered in my consulting practice.

Forgettable Payloads Store the sensitive payload of an event in a separate store to control access and removal.

Crypto-Shredding Encrypt sensitive information in an event and delete the key.

Explicit Public Events Mark a small subset of events as public, keep the rest private by default.

Fat Event Add redundant information to a Domain Event to reduce complexity in the consumer.

Segregated Event Layers Explicitly segregate a Bounded Context’s events in visibility layers, with their own language.

Passage of Time Event Replace cron jobs and scheduled commands, with an agnostic event to indicate the passage of time.

Completeness Guarantee Design the set of Domain Events from a producer so that they can be used to rebuild the producer’s state.

Domain Query Replace Free Queries with Domain Queries to decouple from knowledge of the server’s internals.