kenny.weave-it.org
Co-author Collaborative Software Design: How to facilitate domain modeling decisions. Independent consultant & trainer specialised in technical leadership, software architecture, and #sociotechnical systems design. #DDD #TeamTopologies #DeepDemocracy
441 posts
1,042 followers
621 following
Regular Contributor
Active Commenter
comment in response to
post
Beyond the confirmed Dutch course, an English edition is available on September 15th and 16th in Amsterdam.
More details can be found here: connected-movement.com/course/domai... - 5/5
comment in response to
post
This emphasis on better collaboration between diciplines inspired the 'DDD for Product Management' course. It teaches how to apply principles for more effective collaboration and building better digital products , as I also write about in the co-authored book Collaborative Software Design! - 4/5
comment in response to
post
I'm 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 @settling-mud.bsky.social and [email protected] giving a joint keynote is a fantastic development and a great sign. - 3/5
comment in response to
post
Kicking off with my hands-on collaborative modeling lab with Kristzina, @maxsc.bsky.social and @hschwentner.bsky.social which seems to be full! It's always a highlight of the year, and I'm keen to see who's attending. - 2/
comment in response to
post
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:
devopsdays.org/events/2025-...
comment in response to
post
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. 3/4
comment in response to
post
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! @thomaskrag.bsky.social and I are presenting at #Devopsdays Amsterdam on User Needs Mapping. 2/4
comment in response to
post
Is that a new hope for you?
comment in response to
post
While my DDD training often helps groups take those essential 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. - 10/10
comment in response to
post
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. -9/10
comment in response to
post
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. - 8/10
comment in response to
post
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. 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. - 7/10
comment in response to
post
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. - 6/10
comment in response to
post
In either scenario, it takes more effort and makes adapting far harder when those core business concepts shift.
Now, there's this notion that AI will simply let us "vibe code" our way through development. - 5/10
comment in response to
post
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? - 4/10
comment in response to
post
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." 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! - 3/10
comment in response to
post
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. - 2/10
comment in response to
post
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: speakerdeck.com/baasie/enabl... Enjoy! 7/7
comment in response to
post
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.
6/7
comment in response to
post
It's a practical take on Wardley Mapping (thanks to @richallen.info for coining that), which can "bring a shared understanding of the landscape between teams, and between stakeholders and managers together." 5/7
comment in response to
post
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. 4/7
comment in response to
post
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.
3/7
comment in response to
post
I talked about enabling aligned decentralised architecture decisions. I ended up presenting solo this time, as @thomaskrag.bsky.social unfortunately couldn't make it.
This lack of a map is a big part of why empowering teams, while crucial, can be so tricky. 2/7
comment in response to
post
comment in response to
post
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.
Hope to see you at DDD Europe in just over two weeks! More info:
2025.dddeurope.com/program/inte...
comment in response to
post
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.
comment in response to
post
Kristzina, @maxsc.bsky.social, @hschwentner.bsky.social, or myself will facilitate one of the tools (can you guess which?). Working in small groups, we'll model the problem from these different angles.
comment in response to
post
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.
9/9
comment in response to
post
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. 8/9
comment in response to
post
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.
7/9
comment in response to
post
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. 6/ 9
comment in response to
post
We explored how team types and interaction modes serve as heuristics and constraints, allowing for the intentional modelling of team dynamics – ideally, a collaborative effort with the teams themselves. 5/9
comment in response to
post
This provided a practical means to dive deeper into the strategic context mapping patterns.
Subsequently, our attention shifted to the sociotechnical system through the lens of Team Interaction Modelling from Team Topologies. 4/9
comment in response to
post
The process of modelling the information flow between Bounded Contexts highlighted the coupling it introduces, not only between systems but also in terms of the depth of understanding required between different teams' domains. 3/9
comment in response to
post
Domain Message Flow Modelling. This approach enabled us to trace the impact of specific design choices, such as increased asynchronous communication between Bounded Contexts, through the entire sociotechnical system, observing its direct consequences on aspects like user experience design. 2/9
comment in response to
post
We’ll conclude by discussing how to organise architecture within and between teams and further explore facilitating software architecture.
If you are curious about how these training might help you, feel free to contact me!
6/6
comment in response to
post
core domain charts and the bounded context canvas. The afternoon will be about categorising teams around bounded contexts with Team Topologies, Team interaction modelling, and user needs mapping. 5/6
comment in response to
post
assess the relationships between the bounded contexts that emerged during the decomposition.
Today, we are continuing to connect bounded contexts and analyse the essential complexity within the whole design using Domain Message Flow Modelling. Afterwards, we'll strategise with 4/6
comment in response to
post
where stakeholders share their knowledge and you identify them – or designing Bounded Contexts collaboratively with stakeholders in the solution space. We wrapped up with some sociotechnical systems theory and used context mapping to 3/ 6
comment in response to
post
through facilitating software architecture.
Yesterday, the focus was on decomposing domains into subdomains from a big picture EventStorming. We concentrated on the difference between distilling or decomposing (sub)domains in the problem space – 2/6