It teaches how to apply DDD principles for more effective collaboration and building better digital products together, as I also write about in the co-authored book Collaborative Software Design!

Beyond the confirmed Dutch course, an English edition is available on September 15th and 16th in Amsterdam.

More details can be found here: https://connected-movement.com/course/domain-driven-design-voor-product-management/

I'm particularly thinking about whether we'll see more product managers this year. I've long pushed for better collaboration between architecture/development and product management, so @xinyao and johncutlefish@mastodon.social giving a joint keynote is a fantastic development and a great sign.

This emphasis on better collaboration between these diciplines was the inspiration for my 'Domain-Driven Design for Product Management' course. - 2/

Good news for those interested: my Domain-Driven Design for Product Management course on June 23rd and 24th in Utrecht (in Dutch) is confirmed and running!

Meanwhile, I'm heading to @dddeu today. Kicking off with my hands-on collaborative modeling lab with @yellowbrickc, @__maxs__ and @hschwentner which seems to be full! It's always a highlight of the year, and I'm keen to see who's attending. - 1/3

We'll share practical insights on how to reduce that intrinsic and extraneous load when making crucial architectural choices.

It's going to be a great time – a truly community-driven event with plenty of opportunities to network. Don't forget to use the discount code #FRIENDS_OF_SPEAKERS for 20% off a regular 2-day ticket. Seriously, these tickets go fast!

Buy your ticket(s) here:
https://devopsdays.org/events/2025-amsterdam/registration

Ever feel like your brain is overflowing when making architectural decisions that impact other teams in the organisation? It's a common challenge, especially as teams become more autonomous. Without a solid grasp of user needs, value chains and team boundaries, those decisions can quickly add to your cognitive load.

If you're going to be in Amsterdam on June 18th, you're in luck! Thomas and I are presenting at #Devopsdays Amsterdam on User Needs Mapping. 1/2

That real-world immersion helped me recognize and shed the less effective skills I’d been taught, revealing how software engineering truly needs to function to maintain adaptability and resilience in the face of organizational changes.

DDD training often helps groups take those first steps, I can't shake the feeling that if we don't fundamentally change how people are educated from the outset, we're simply expending too much effort trying to fill an ever-growing need for developers. - 6/6

Back then, it was simply expected that developers understood the business. My first month, I got a two-day workshop focused entirely on asset management. I was applying Domain-Driven Design, robust OOP principles, and practical software architecture, working with 120 services in an event-driven system, deploying to production multiple times a day, even on Fridays. - 5/6

Now, there's this notion that AI will simply let us "vibe code" our way through development. But that’s just automating the creation of code, often built on the same foundational principles of abstraction and "platonic" thinking that cause problems in the first place. The outcome will be the same, just delivered faster. We're still missing the mark on teaching the crucial skills I was fortunate enough to gain in my first six years in the industry. - 4/6

But seriously, what is inherently wrong with code duplication? As long as we can quickly modify it when business needs evolve, there's no problem! What we should be concerned about is conceptual duplication. Is a single business concept being duplicated in multiple areas? Or, conversely, are two or more distinct business concepts abstracted together in one place in your code? In either scenario, it takes more effort and makes adapting far harder when those core business concepts shift. - 3/6

When I teach Domain-Driven Design, I often hear the familiar argument: "But that causes so much code and data duplication!" We're drilled to believe code duplication is bad, that we need strict abstraction and single responsibility, keeping data in one place. That’s the OOP paradigm most of us, myself included, were taught. My usual comeback, only half in jest, is, "Yeah, SonarQube won't like it." - 2/6

I’m seeing it more and more clearly: the way we teach computer science and programming is actually counterproductive to creating the adaptive software that most organizations need to thrive. With the rise of AI, it's becoming undeniable that we're focusing our efforts on the wrong skills. - 1/6

It’s really about making collaboration intentional with the teams and making dependencies in the value chain visible so teams can act with informed autonomy.

For everyone who asked or couldn't make it, the session video will be available soon! And if you want to dive into the details right away, the slides are now up on Speaker Deck: https://speakerdeck.com/baasie/enabling-aligned-decentralised-architecture-decisions-through-user-needs-mapping Enjoy! 4/4

So, the crucial question I explored was, "How can teams have a shared understanding of the system they are building software in?" A key part of the answer, I believe, is User Needs Mapping. It's a practical take on Wardley Mapping (thanks to Rich Allen for coining that), which can "bring a shared understanding of the landscape between teams, and between stakeholders and managers together." 3/4

This lack of a map is a big part of why empowering teams, while crucial, can be so tricky. When "teams gain independence, system-impact decisions made without deep understanding become a direct route to increased cognitive load." We're aiming for flow, not more friction and confusion.
2/4

Teams are part of a larger sociotechnical system. Without a map of this landscape, it's difficult for them to understand the true impact of their architectural decisions on the overall system." This was a core point I dug into during my session at NDC Conferences Oslo yesterday, where I talked about enabling aligned decentralised architecture decisions. I ended up presenting solo this time, as Thomas Krag unfortunately couldn't make it.

1/4

We prepped for this yesterday, and it's shaping up to be a focused, hands-on experience. Spots will be limited to 7 participants per facilitator to ensure everyone can get deeply involved. 2/3

Hope to see you at @dddeu in just over two weeks! Check out the session here:
https://2025.dddeurope.com/program/interactively-designing-distributed-systems-integration-with-collaborative-modelling/

3/3

Working in small groups, we'll model the problem from these different angles. The idea is to give participants a genuine feel for these collaborative modelling sessions. Afterwards, we'll reflect together on the pros and limits of each approach, helping everyone build a better sense of which tool fits what situation, particularly for designing distributed system integrations. 2/3

Something special is happening in two weeks at @dddeu. We're running a hands-on session where we'll tackle one problem using four distinct collaborative modelling tools: Domain Storytelling, EventStorming, Wardley Mapping, and Domain Message Flow Modelling.

@yellowbrickc, @__maxs__, @hschwentner, or myself will facilitate one of the tools (can you guess which?).
1/3

Over the two days, our progression moved from Big Picture EventStorming to identifying (sub)domains, then to designing Bounded Contexts, and finally to structuring teams with Team Topologies. Throughout this journey, the consistent use of modelling tools allowed for continuous engagement with the design, incorporating the wisdom and trade-offs identified by those directly involved in building the software, and fostering sustainable architectural decisions with broad agreement.
5/5

It became evident that many organisations tend to emphasize team types while missing the crucial focus of Team Topologies: establishing a shared language for teams and leadership. This shared language is instrumental for discussing the trade-offs of an intended design and for navigating the dynamic nature of teams, including member transitions and evolving needs during the implementation of a new design.

4/5