<<< Previous speaker next speaker >>>

Eric Evans, Mr. Domain-Driven Design

 Eric  Evans

Eric Evans is a specialist in domain modeling and design in large business systems. Since the early 1990s, he has worked on many projects developing large business systems with objects and has been deeply involved in applying Agile processes on real projects.

Out of this range of experiences emerged the synthesis of principles and techniques shared in the book "Domain-Driven Design," Addison-Wesley 2003.

Eric now leads Domain Language, Inc., a consulting group which coaches and trains teams to make their development more productive and relevant through effective application of domain modeling and design.

Presentation: "Strategic Design: Avoiding Responsibility Traps"

Time: Wednesday 16:30 - 17:30

Location: Stanford


As software development leaders, we need to think more strategically. Some design decisions affect the trajectory of the whole project or even the organization. These decisions arise in early chartering and throughout development, and they are about much more than architecture. This talk will examine these issues through the lens of the Strategic Design principles of domain-driven design, which systematize a few critical practices some successful teams do intuitively.

It is common for skilled teams to deliver software they are not proud of, due to compromises with legacy designs. Others toil for years, producing a platform that is never used to good advantage. These are strategic failures. On the other hand, there are projects with a direct explanation of how the software contributes to business goals. There are projects where designers work with a realistic view of the context of their development within the larger system, allowing them to maintain design clarity and integrity. These are strategic successes. Winning strategy starts with the domain.

Two domain-driven design principles, "Context Mapping" and "Distilling the Core Domain", help you see your strategic situation more clearly and approach strategic design decisions more systematically. These techniques require extensive interaction with domain experts as well as the leaders of the organization, in discussions broader than functional requirements. They sometimes lead to priorities quite different from our most comfortable notions.

Presentation: "Sustainable Design for Agile Teams"

Time: Friday 10:10 - 11:10

Location: Stanford

Abstract: Too many teams interpret "Agile" as a permit to not think about design. But if they have ambitious goals, Agile teams need more than standup meetings and iterations. Many teams get off to a quick start, building lots of features in early iterations, but end up with a "Big Ball of Mud". Without clear and well-structured code, they cannot sustain their pace and also put themselves at risk of, one day, encountering a critical feature they simply cannot deliver. Without the common understanding between developers and stakeholders that is forged in domain analysis, one of the greatest benefits of iteration, the deepening communication about what the software should do and how it should do it, is never realized.

We don't want to return to the "Analysis Paralysis" that we used to endure (and that many teams still do), but interpreting "Do the Simplest Thing" as "Do the Easiest Thing" doesn't work either.

This talk will consider ways of incorporating modeling and design into the iterative process in a lightweight way that increases communication with stakeholders and decreases the likelihood of painting ourselves into corners, without returning to the dead-hand of the analysis phase. As a concrete example of how such techniques can be incorporated into the Agile framework, we'll have an overview of a simple process Domain Language has used with its clients for the last six years. The right kind of modeling and design, far from bogging down a project, leads to a livelier and more sustainable development pace.

Training: "DDD Basics"

Track: Tutorial

Time: Monday 09:00 - 12:00

Location: Stanford

Large information systems need a domain model. Development teams know this, yet they often end up with little more than data schemas which do not deliver on the productivity promises for object design. This tutorial delves into how a team, developers and domain experts together, can engage in progressively deeper exploration of their problem domain while making that understanding tangible as a practical software design.
This model is not just a diagram or an analysis artifact. It provides the very foundation of the design, the driving force of analysis, even the basis of the language spoken on the project.

The tutorial will focus on three topics:
-The conscious use of the ubiquitous language on the project to refine and communicate models and strengthen the connection with the implementation.
-Forging an effective collaboration with domain experts.
-Key modeling patterns, such as aggregates, which are often not given enough attention.

The tutorial will include discussion of selected patterns from the book "Domain-Driven Design," Addison-Wesley 2004, and video reenactments of domain modeling scenarios.

Objectives: Awareness of the fundamental points of DDD at the tactical level in a development project.

Format: Combination of presentation & discussion

Training: "DDD Strategy"

Track: Tutorial

Time: Monday 13:00 - 16:00

Location: Stanford

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. A related issue: modeling is best carried out by small, dynamic teams with a lot of autonomy, yet creating large systems requires coordination and project-spanning decisions. Managers and developers alike need to pay close attention to this intersection of design, project organization, and politics. This tutorial will introduce them to a suite of techniques for that purpose.

First, distilling a shared vision of the system's core and the roles of its parts can focus development effort on real business assets, and tell when 'good enough good enough' versus when to push for excellence.

Then, "context mapping" addresses a vital fact of life: different groups model differently. Ignoring these realities leads to dumbed-down models and costly, buggy integrations, and disruption of project plans where they depend on other teams.

Objectives: Awareness of the factors that endanger the ambitions of a complex software project and the tools DDD provides for dealing with them

Combines lecture, reenactment of typical scenarios, and discussion.