|
|
|
<<< Previous speaker
|
next speaker >>>
|
Eric Evans, Mr. Domain-Driven Design
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
Abstract: 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"
Time:
Monday 09:00 - 12:00
Location:
Stanford
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 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"
Time:
Monday 13:00 - 16:00
Location:
Stanford
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 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
Format: Combines lecture, reenactment of typical scenarios, and discussion.
|
 |
| |
