Event-driven architectures give us the ability to create scalable, resilient and decoupled applications, coupled with domain-driven design principles we can start to use events as a form of communication between bounded contexts and teams.

Conway’s law suggests that the architecture of the system we build is a reflection of the teams that built it, and when we couple with this domain-driven design and identify our bounded contexts and domains we start to naturally create domains and systems that exist in their own right and are decoupled from each other (sounds very similar to some of the benefits to event-driven architectures).

Agility with EDA

A great benefit of event-driven architectures is the agility it can provide technical teams and also feature development. When producers raise events, consumers come and go and choose to listen to the events (if they are interested).

EDA based architectures give organisations the ability to add more consumers to existing events, and as this catalog of events grows over time, more innovation and value can be captured.

As you add more consumers, no doubt you might also add new bounded contexts which in reflect would affect your team structure (Conway’s law).

Connection between EDA, DDD and Conway’s Law

There is a connection between domain-driven design, event-driven architectures and Conway’s law, it’s important to consider that when designing and implementing your applications, you might event see a natural org structure forming around your EDA solution and vice versa.

Extra Resources

• EDA coupled with DDD - Event driven architecture and domain-driven design work well together. Here is a visual to help you understand.
• Messaged between bounded context - Event design is important between bounded context, this visual explains mapping techniques for messages before you consume them.
• EventStorming - Use EventStorming to highlight your bounded context and events, this could help identify team structure and future org structure.
• EDA is a journey… you won’t get it right first time - EDA is a journey as you identify domains, events, patterns, org structures, it will take time, and that’s OK.
• Scaling EDA can be hard without docs - Some thoughts around documenting your EDA applications. As you grow you will need to discover events, producers and consumers.
• Conways law with Event Architectures - Some thoughts on Conways law from Martin Fowler and a mention of domain-driven design.
• Conways law and microservices - Short post on Conways law, DDD and microservices.