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.
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.
