Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure. Self-organizing, cross-functional (Pod) teams organised around business capabilities with the ability to release their own software to production are the way forward. These videos provide an introduction to these concepts and the thinking behind them.
Strategic enablement of foundational architecture in your platform can help your product and IT teams discover new ways to create value from your organizational assets. We’ll present value-driven approaches to building these necessary capabilities into the platform, paths to follow, and traps to avoid.
A descriptive, in-depth walk-through for applying Domain-Driven Design principles in practice.
Eric Evans is the author of “Domain-Driven Design: Tackling Complexity in Software”. This a good conference talk to that outlines the basic concepts of Domain Driven Design.
Very interesting 12 episode podcast that discusses Distributed Architecture, CQRS, Event Sourcing, DDD. With Rinat Abdullin, Jonathan Oliver, Jimmy Bogard.
An interesting debate about Microservices from highly respected panelists; Fred George, Rod Johnson, Jessica Kerr, Michael Nygard, Sam Newman.
The greenfield project started out so promising. Instead of devolving into big ball of mud, the team decided to apply domain-driven design principles. Ubiquitous language, proper boundaries, encapsulation, it all made sense.
Greg Young — A Decade of DDD, CQRS, Event Sourcing Domain-Driven Design Europe 2016 – Brussels, January 26-29, 2016 Gregory Young Gregory Young coined the term “CQRS” (Command Query Responsibility Segregation) and it was instantly picked up by the community who have elaborated upon it ever since. Greg is an independent consultant and serial entrepreneur. He has 15+ years… Continue reading "Greg Young — A Decade of DDD, CQRS, Event Sourcing"
Microservices are associated with extreme isolation (e.g. no shared database, autonomous dev-ops teams, etc.) At its best, this creates a practical boundary within which modeling and design have a chance to thrive. In Domain-driven Design (DDD) we call this a “Bounded Context”.
People describe their systems as “event-driven”. But when looking deeper that phrase seems to lead to some very different architectural assumptions.