A few days ago I had a chance to give a talk on software design in Barcelona. The event was organized by Barcelona Software Craftsmanship group and hosted by eBay Enterprise International.
Plan for the class looked like this:
- Principles of software design - principles of the Software Design Process, DDD and decomposition, importance of fast feedback loop and iterations, boundaries and contracts. Divide and conquer principle. Domain events and API contracts as the core part of interchange contexts and enforcing long-term stability.
- Event Storming Overview - audience was too large to run an event-storming session within the conference. Instead we went though the theoretical aspects of event storming and various uses.
- Practical application of event-driven model - split domain implementation into modules; capture behaviors with verifiable use cases expressed via domain-events and API contracts; scale design to handle more features, team members and higher loads; high availability.
- CQRS Beers - an informal discussion, focused on QA, actual code and implementation details. We talked about CQRS/DDD principles, command buses, asynchronous UI updates, handling high load and ReactJS/FLUX.
I enjoyed the class and the beers afterwards. Many thanks to Alvaro García, Manuel Rivero, Cabre Barrera and Villazala Gordo for the invitation and organization of the event. Thanks to Angel Rojo for the photo.
These additional materials contain more information on the topics covered during the workshop. They can also provide answers to some questions we didn't have time to address.
- Sample modular backend for TODO app - work in progress, but already includes these use cases I showed during the workshop.
- HappyPancake Story - story of a HappyPancake project, covering many aspects of event-driven design, "micro-services", specifications and event-driven UI. Check this story, the others and simply browse the site.
- Being The Worst - light-hearted podcast on domain-driven design, implementation patterns and learning how to build a task manager. We are still doing it.
- Domain-driven Design - the foundational book by Eric Evans on DDD methodology and related patterns. Start reading it with the chapter on context Mapping. Keep in mind that "Domain Events" weren't considered to be very important when the book was written (things have changed since then).
- Implementing DDD - newer book by Vaughn Vernon, addressing some concerns and questions which appeared since the "Blue Book" came out. Don't read the appendix on Event Sourcing, material there is very outdated.
- Ziobrando's Lair - blog by Alberto Brandolini, a great guy and an experienced DDD practitioner that coined term "event storming".
References above are most closely aligned with the material given during the workshop. If you have more specific questions, please don't hesitate to get in touch.
I enjoyed a lot the talk by Rinat... Interesting round of Q&A after the session and thanks to eBay to provide the snacks and drinks!
Masterclass on event driven design by @abdullin thanks for all the food for thought!
...really enjoyed the presentation of @abdullin about event driven software
The important is in the white spaces. Great talk. Thanks @abdullin @eBayESP @bcnswcraft
@abdullin really good talk today at meetup ;)
@abdullin thanks for the very interesting and information-packed conference at @eBayESP about #DDD and #eventDriven
- What did you like the most? I enjoyed a lot the explanation of emergent design from a DDD standpoint, event storming and all the discussion around domain events.
- What could make this class better? It would be very interesting to explain all these concepts just working on a simple problem and following all the steps you described on the emergent design with the same problem. For instance, the typical TODO list application how it would be implemented following the DDD approach.
- What else would you like to learn about? I think it would be very useful to do a practical workshop and work on a problem and practice event storming, context mapping, develop some component using tactical design patterns, measure and then, refactor it in a second sprint.