|
Notes from presentations are available on this site (if the presenter has provided
us with his/her materials). Simply go to the PROGRAM link and click on the session. |
Domain-Driven Design: Strategy
Eric Evans (Domain Language, Inc.)
Tutorials · Developing
Friday, 08:30, 3 hours 30 minutes | Renaissance East
Agile teams aim to adapt quickly and adapt the system quickly to new learning and new conditions. Some design decisions affect the trajectory of the whole project, and so a team serious about agility must attend to certain vital aspects of the design. Agile teams aim to make software that is valuable to the customer. To make sure that development is being invested in the part of the software with core value to the business requires a deeper conversation about the domain that usually happens in typical planning sessions. In fact, modeling and agility are tightly connected on a complex project. 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. Modeling is most needed in complex circumstances, yet the typical dynamics of large projects often derail modeling or disconnect it from the real design. This tutorial introduces 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 is 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 blinding 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.






