This site uses cookies to improve your experience. To help us insure we adhere to various privacy regulations, please select your country/region of residence. If you do not select a country, we will assume you are from the United States. Select your Cookie Settings or view our Privacy Policy and Terms of Use.
Cookie Settings
Cookies and similar technologies are used on this website for proper function of the website, for tracking performance analytics and for marketing purposes. We and some of our third-party providers may use cookie data for various purposes. Please review the cookie settings below and choose your preference.
Used for the proper function of the website
Used for monitoring website traffic and interactions
Cookie Settings
Cookies and similar technologies are used on this website for proper function of the website, for tracking performance analytics and for marketing purposes. We and some of our third-party providers may use cookie data for various purposes. Please review the cookie settings below and choose your preference.
Strictly Necessary: Used for the proper function of the website
Performance/Analytics: Used for monitoring website traffic and interactions
This is the question I get asked the most, so I’ve put together this article describing a workshop recipe you can use. In Domain-Driven Design, a large system is decomposed into bounded contexts , which become natural boundaries in code as microservices and as teams in the organisation. 30 minutes) Bounded Context Design Canvas (min.
There are a few qualities that differentiate average from high performing software engineering organisations. I believe that attitude towards the design of code and architecture is one of them. Both valuing design and striving for continuous delivery are necessary. So we need to make it part of everything we do.
My participation at these conferences is a mixture of talks and workshops. I’ve used Miro exclusively for my in-person workshops and talks, and I plan to for all upcoming events. Miro for In-person Workshops? At NDC Porto 2022, I teamed up with Maxime Sanglan-Charlier to run our 2 hour softwarearchitecture-themed workshop.
If you would like to learn or practice how to break up a large business into domains and use them as the foundation for your softwarearchitecture and team organization, I have created a strategic domain-driven design kata that you may find useful. Who to invite? I recommend organising attendees into groups of 4–5 people.
As we can observe, the investment and involvement of the AMET tend to follow a bell curve, where there is increasing investment and involvement of the AMET in the modernization initiative to facilitate the necessary design and upskilling needed to improve the architectural capability.
Domain-Driven Design is an approach to designing systems, usually software, that emphasises creating a common language between domain experts and system builders. Here’s an example I use in talks and workshops: How to group these concepts into domains? This is normal, embrace the fuzziness and apply design thinking.
There are thousands of ways we can shape the software systems we build and organise our teams around them. Yet there is no flowchart we can simply follow to find the optimal design. The products themselves are software systems which grow harder and harder to reason about as they scale and age.
Mapping out your business’s domain landscape has many benefits: knowledge sharing, generating product ideas, providing the foundation for softwarearchitecture, aligning on requirements, but a common challenge is… “where do we start?” The following steps are my baseline format for a series of discovery workshops.
I’ve just created a new kata which you and your team/friends can use to practice your architecture and domain-driven design skills. You can find out more about that here: [link] This kata is based on content from my workshops. This kata is split into four sections that address different aspects of architecting software systems.
The team can become a bottleneck for many other teams, and this design choice can be the result of elevated organisational politics. This is a high level of coupling between the contexts and the teams that own them. If you have opinions or experiences, your comments on this article are more than welcome or you can contact me directly.
Perhaps led by strong managers, they will fight vehemently for their work to be prioritised and software systems to be designed to their needs. This organisational pattern can be mirrored in the softwarearchitecture, emphasising the sociotechnical nature of systems. These concepts also apply to distributed architectures.
One of the challenges I see regularly is inertia following domain discovery workshops. Start by mapping out the current state of your domains If you’re not sure what your domains are, I have created a Strategic DDD Kata which provides a scenario for you to practice designing domain boundaries.
The techniques we use for visual, collaborative domain modelling are designed for in-person events, where everybody is in the same physical space. We will be running a remote-optimised domain-driven designworkshop on 15–16th June where we will use some of the techniques discussed in this post and many others, like the bounded context canvas.
In every workshop, I always ask everyone “Imagine there is no text here. What do you read from the image below, and what might you propose to do next in the workshop? You can do this with almost any visual workshop technique. What is this arrangement of colours and shapes telling you?”.
You can also experiment with various workshop formats. You can mix working alone, pairs, whole group activity, and other design aspects to design group experiences that give everyone in the team a voice and a chance to share their thoughts before merging responses.
Evolving Your Aggregates Over Time The initial criteria on which you base your aggregate design is likely to change over time. If you’d like to go through the whole process of modelling domains, shaping the softwarearchitecture, and finding aggregates, join my 2 day workshop at DDD EU in February 2020.
Loosely-coupled teams enabled by loosely-coupled softwarearchitecture is one of the strongest predictors of continuous delivery performance and organizational scaling. Decoupling Streams of Work Our goal when designing systems is to maximise the speed of delivery and value of the work we deliver.
Many of the practices that enable teams to move quickly are the same practices that enable highly-reliabile systems: automation, observability, testing, and design. I suggest regular domain discovery workshops to identify hidden domain coupling. It doesn’t need to be a choice of one over the other.
We organize all of the trending information in your field so you don't have to. Join 5,000+ users and stay up to date on the latest articles your peers are reading.
You know about us, now we want to get to know you!
Let's personalize your content
Let's get even more personalized
We recognize your account from another site in our network, please click 'Send Email' below to continue with verifying your account and setting a password.
Let's personalize your content