Innovation and loose coupling

Innovation happens when we connect people together, solving issues and problems. Part of domain-driven design is connecting people, connecting domain experts with the solution that is being built and the people building it. It’s only when we connect and understand our domain is we can start to innovate and build new solutions that can help. Couple this with event-driven architectures giving us a loose coupling between bounded context and services, we can reuse events and create new consumers when new requirements or innovation is required.

Shared Understanding

Some of the best people I have worked with have a shared understanding of the domain they are working in, using the same terminology and modelling the domain into code, this can take time but well worth the effort. It’s important to create that ubiquitous language.

Knowledge continues to grow

Your domain is organic and your requirements and domain will evolve over time, once you have a map of your domain, it will continue to change. Be prepared for that.

Events understood outside tech

When events are understood outside of the technical implementation new ideas can be generated. When domain experts or business owners understand domain events (events important to them/the business), they can start to come up with new features or solutions based on events that are already being dispatched vs having to write code from scratch. I have seen teams fly here.

Code maps to conversations

When the domain is understood we can translate this into code, the code represents the domain, and our code can start to map to real conversations we are having. When you have well defined events these event names can be and will be brought up into conversation.

Identify levels of events

When you highlight your bounded context, you will be using events inside and outside of your domain context. Internal vs External events, knowing the difference here can help. Identify, what is important for the business.

Extra Resources

• What is domain driven design? - Wiki page for DDD, start here to get a quick overview, although DDD is huge, it will take more than this page to understand.
• What is domain driven design? Continued… - A nice summary from Mathias Verraes about DDD, worth reading.
• Domain Driven Design and Event-Driven Architecture Podcast - Vaughn Vernon gives a podcast that dives into EDA and DDD. If you want to dive deeper worth a listen.
• Explicit vs Implicit events - Producers and consumers, how do they know what is in the event? Do they have a shared understanding? We are coupled but nothing stops us documenting, right?
• Eventstorming - Want to get started, trying to find events and your bounded context. Start with EventStorming.
• Document your event-driven architecture - Not really too much to DDD, but documentation can help you and your business find events and try and get that shared understanding.
• Event first thinking - Something I’m passionate about, think about events as first class citizens of your EDA design, use DDD to help model them.
• Ubiquitous Language - What is Ubiquitous Language? Visual to help.
• Messages between bounded context - How can we transform messages between contexts? Three patterns here.