<<< Previous speaker Next speaker >>>

Eric Evans, Domain Language Inc.

 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"

Track:   Modeling

Time: Tuesday 13:00 - 14:00

Location: Conference Hall 3

Abstract:

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 talk 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. It can guide decisions about what do develop in-house, what to buy, and even where agile processes will matter most.

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. Defining the boundaries within which these various models apply allows a team operating within such a boundary to iterate and refine its model and design without being suffocated by interdependencies with other teams, yet without blindly slamming into insurmountable integration problems. The combination of context mapping and distillation of the core domain provides a powerful view of the big picture.

Finally, who makes such decisions and how? Architecture teams disconnected from daily development make decisions with unintended consequences. Agile processes emphasize staying close to the hands-on development work, but such decisions also need a broad view. Without prescribing a particular organization, we will consider guidelines for strategic decision making.

Password protected Download slides

Tutorial: "Domain Driven Development"

Track:   Tutorial

Time: Friday 09:00 - 16:00

Location: SAS Dania

Abstract: 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 look at both tactical and strategic issues. Tactically, we will examine the use of language on the project to refine and communicate models and strengthen the connection with the implementation, and iterative redesign and refactoring aimed at deepening model insight (in addition to making technical improvements to the code). Strategically, we will look at context mapping and distilling the core domain. These are the decisions where design and politics often intersect.

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