Eric Evans is the author of “Domain-Driven Design: Tackling Complexity in Software,” Addison-Wesley 2004.
Since the early 1990s, he has worked on many projects developing large business systems with objects with many different approaches and many different outcomes. The book is a synthesis of that experience. It presents a system of modeling and design techniques that successful teams have used to align complex software systems with business needs and to keep projects agile as systems grow large.
Eric now leads “Domain Language”, a consulting group which coaches and trains teams applying domain-driven design, helping them to make their development work more productive and more valuable to their business.
What does Domain-Driven Design look like in 2017? We have more experience now. We have better tools now. We have an architectural environment better suited to DDD than the typical 2003 architecture. Certainly, some people are getting a lot out of DDD -- but not so very many. DDD has always been difficult, and it still is. And we might be held back by some dogmatic notions of what it should look like.
Some design decisions have an impact on the trajectory of the whole project. Modeling is most needed in complex circumstances, yet the typical dynamics of large projects too often derail it or disconnect it from the real design. This course delves into principles for clarifying the big picture, getting effort focused on the core, and coordinating multi-team development.
The target audience is IT Leaders, Development Managers, Enterprise Architects, Software Architects, Senior Developers and Development Leads. We recommend attendees have experience with large systems multi-team development. In this class you will learn how to:
Most of our best examples of model exploration happen behind closed corporate doors. Generic subdomains, such as time, may provide a way to try out approaches to domain modeling more publicly.
Most popular software libraries for managing time are based on similar models, and JodaTime, a common Java library being incorporated into Java 9, is a good example. It has a fairly good model, and illustrates the tendency for the first good idea to be the last idea. Exploration stops as soon as a workable solution is found. While this is actually not such a bad idea in supporting domains, it short-circuits work on the critical core domain.But how do we escape from these good models that stop our thinking? Eric will walk through some rich semantics of an alternate model of time and an associated library to illustrate that there is always another model.
The code is in Clojure, but you don’t need to know Clojure to understand the talk.
Author of “Domain-Driven Design”
Object Design Pioneer
Inventor of Wiki
Author of “Implementing DDD”
Inventor of EventStorming
Serial DDD Advocate
Student of Systems
Java Champion and Author of POJOs in Action
Creator of Axon Framework
UX Expert, Business Analyst and Software Developer
Asker of Inconvenient Questions
Secure Domain Philosopher
Author of Secure by Design, DDD Enthusiast, Coder and Quality Defender
I Model Business Domains For Fun.
Designer or Engineer? Yes!
Intense perfectionist with a passion for DDD and BDD
Full-stack developer. @dddmadrid Organizer
DDD Practitioner and FP aficionado
Shipper of Things
Author of "Head-First Domain-Driven Design" O'Reilly 2018?