Domain Driven Design Chapter 17 Summary

 Chapter 17: Bringing the Strategy Together

• "The preceding three chapters presented many principles and techniques for domain-driven strategic design. In a large, complex system, you may need to bring several of them to bear on the same design."
• Combining Large-Scale Structures and Bounded Contexts
• "The three basic principles of strategic design (context, distillation, and large-scale structure) are not substitutes for each other; they are complementary and interact in many ways. For example, a large-scale structure can exist within one bounded context, or it can cut across many of them and organize the context map."
• "But on many projects, the greater challenge is to understand how disparate parts fit together. They may be partitioned into separate contexts, but what part does each play in the whole integrated system and how do the parts relate to each other? Then the large-scale structure can be used to organize the context map."
• Combining Large-Scale Structures and Distillation
• "The concepts of large-scale structure and distillation also complement each other. The large-scale structure can help explain the relationships within the core domain and between generic subdomains."
• "At the same time, the large-scale structure itself may be an important part of the core domain. For example, distinguishing the layering of potential, operations, policy, and decision support distills an insight that is fundamental to the business problem addressed by the software. This insight is especially useful if a project is carved up into many bounded contexts, so that the model objects of the core domain don’t have meaning over much of the project."
• Assessment First
• "Draw a context map. Can you draw a consistent one, or are there ambiguous situations?"
• "Attend to the use of language on the project. Is there a ubiquitous language? Is it rich enough to help development?"
• "Understand what is important. Is the core domain identified? Is there a domain vision statement? Can you write one?"
• "Does the technology of the project work for or against a model-driven design?"
• "Do the developers on the team have the necessary technical skills?"
• "Are the developers knowledgeable about the domain? Are they interested in the domain?"
• Who Sets the Strategy?
• Emergent Structure from Application Development
• "A self-disciplined team made up of very good communicators can operate without central authority and follow evolving order to arrive at a shared set of principles, so that order grows organically, not by fiat."
• A Customer-Focused Architecture Team
• " An architecture team can act as a peer with various application teams, helping to coordinate and harmonize their large-scale structures as well as bounded context boundaries and other cross-team technical issues. To be useful in this, they must have a mind set that emphasizes application development."
• "[Architecture team] members are true collaborators with development, discovering patterns along with the developers, experimenting with various teams to reach distillations, and getting their hands dirty."
• Six Essentials for Strategic Design Decision Making
• "Decisions must reach the entire team."
• "Obviously, if everyone doesn’t know the strategy and follow it, it is irrelevant. This requirement leads people to organize around centralized architecture teams with official “authority”—so that the same rules will be applied everywhere. Ironically, ivory tower architects are often ignored or bypassed. Developers have no choice when the architects’ lack of feedback from hands-on attempts to apply their own rules to real applications results in impractical schemes."
• "The decision process must absorb feedback."
• "Creating an organizing principle, large-scale structure, or distillation of such subtlety requires a really deep understanding of the needs of the project and the concepts of the domain. The only people who have that depth of knowledge are the members of the application development team. This explains why application architectures created by architecture teams are so seldom helpful, despite the undeniable talent of many of the architects."
• "The plan must allow for evolution."
• "Effective software development is a highly dynamic process. When the highest level of decisions is set in stone, the team has fewer options when it must respond to change. evolving order avoids this trap by emphasizing ongoing change to the large-scale structure in response to deepening insight."
• "Architecture teams must not siphon off all the best and brightest."
• "It is essential to have strong designers on all application teams. It is essential to have domain knowledge on any team attempting strategic design. It may simply be necessary to hire more advanced designers. It may help to keep architecture teams part-time. I’m sure there are many ways that work, but any effective strategy team has to have as a partner an effective application team"
• "Strategic design requires minimalism and humility."
• "Distillation and minimalism are essential to any good design work, but minimalism is even more critical for strategic design. Even the slightest ill fit has a terrible potential for getting in the way. Separate architecture teams have to be especially careful because they have less feel for the obstacles they might be placing in front of application teams. At the same time, the architects’ enthusiasm for their primary responsibility makes them more likely to get carried away."
• "Objects are specialists; developers are generalists."
• "The essence of good object design is to give each object a clear and narrow responsibility and to reduce interdependence to an absolute minimum. Sometimes we try to make interactions on teams as tidy as they should be in our software. A good project has lots of people sticking their nose in other people’s business. Developers play with frameworks. Architects write application code. Everyone talks to everyone. It is efficiently chaotic. Make the objects into specialists; let the developers be generalists."
• The Same Goes for the Technical Frameworks
• "Technical frameworks can greatly accelerate application development, including the domain layer, by providing an infrastructure layer that frees the application from implementing basic services, and by helping to isolate the domain from other concerns. But there is a risk that an architecture can interfere with expressive implementations of the domain model and easy change."
• "Don't write frameworks for dummies"
• "Team divisions that assume some developers are not smart enough to design are likely to fail because they underestimate the difficulty of application development. If those people are not smart enough to design, they shouldn’t be assigned to develop software. If they are smart enough, then the attempts to coddle them will only put up barriers between them and the tools they need.
  
  This attitude also poisons the relationship between teams. I’ve ended up on arrogant teams like this and found myself apologizing to developers in every conversation, embarrassed by my association. (I’ve never managed to change such a team, I’m afraid.)"
• Beware the Master Plan
• "A group of architects (the kind who design physical buildings), led by Christopher Alexander, were advocates of piecemeal growth in the realm of architecture and city planning. They explained very nicely why master plans fail."
• "Without a planning process of some kind, there is not a chance in the world that the University of Oregon will ever come to possess an order anywhere near as deep and harmonious as the order that underlies the University of Cambridge.
  
  The master plan has been the conventional way of approaching this difficulty. The master plan attempts to set down enough guidelines to provide for coherence in the environment as a whole—and still leave freedom for individual buildings and open spaces to adapt to local needs.
  
  . . . and all the various parts of this future university will form a coherent whole, because they were simply plugged into the slots of the design.
  
  . . . in practice master plans fail—because they create totalitarian order, not organic order. They are too rigid; they cannot easily adapt to the natural and unpredictable changes that inevitably arise in the life of a community. As these changes occur . . . the master plan becomes obsolete, and is no longer followed. And even to the extent that master plans are followed . . . they do not specify enough about connections between buildings, human scale, balanced function, etc. to help each local act of building and design become well-related to the environment as a whole.
  
  . . . The attempt to steer such a course is rather like filling in the colors in a child’s coloring book . . . . At best, the order which results from such a process is banal.
  
  . . . Thus, as a source of organic order, a master plan is both too precise, and not precise enough. The totality is too precise: the details are not precise enough.
  
  . . . the existence of a master plan alienates the users [because, by definition] the members of the community can have little impact on the future shape of their community because most of the important decisions have already been made.
  
  —From The Oregon Experiment, pp. 16–28 (Alexander et al. 1975)"
• "Alexander and his colleagues advocated instead a set of principles for all community members to apply to every act of piecemeal growth, so that “organic order” emerges, well adapted to circumstances."