DDD.17 – Bringing the strategy together

Strategic design is composed by 3 complementary principles:

1. Context (Context map, bounded context)
2. Distillation (Core Domain)
3. Large scale structure (Evolving order)

Project assessment

1. Draw a context map
2. Establish or refine the Ubiquitous Language
3. Define what is the core domain
4. Is the technology adequate for DDD/MDD ?
5. Assess the team developers skills to match them to the project complexity
6. Are the developers knowledgeable and engaged in the domain?

Who sets the strategy?

Ivory tower architect

This is an organizational style that has an architect which analyses the project at hand and determines the strategy before the project starts to be developed. This fits with the waterfall project management style but goes against the DDD approach, based in an Agile methodology and evolutive architecture.

Emergent structure from application development

Typically, in a team doing Extreme Programming, the architectural structure emerges from the development process itself. However, the global design may become inconsistent. In order to keep the global architecture design consistent, it is a good practise to have a strategic design leadership, as a role played by one or several of the team developers.

Customer focused architecture team

This is a team of architects who is there to serve, to help the development teams by collaborating, experimenting, distillating the domain with the developers.

Eric Evans gives us 6 guidelines for this collaboration:

1. Decisions must reach the entire team
   This can achieved by having an architecture team with official authority to formalize rules, or it can be achieved by having the strategy come out of the application development team;
2. The decision process must absorb feedback
   The architecture decision makers need to receive, accept and respond to the development team feedback. This can be achieved through collaboration, and it is a good practise to rotate the architects through the development teams;
3. The plan must allow evolution
   It’s good to have some higher level design rules, but we must be flexible and allow them to change/evolve as needed.
4. Architecture teams must not absorb all good designers
   It is essential to have good designers in all application teams:
   1. In the architecture teams, so that a good design is created
   2. In the development teams, so that the design is properly implemented

   It is essential to have domain knowledge in all application teams:

   1. In the Architecture teams so that the design created matches the domain
   2. In the development teams so that the domain is well reflected in the implementation
5. Strategic design requires minimalism and humility
   We need to not get carried away when creating an architectural design. Over engineering a system will in fact bring more problems than solutions. We need to keep it simple and be humble when our great design idea is found to be, in fact, counter productive.

   Realizing that your best idea is likely to get in somebody’s way takes humility
   pg. 495

6. 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 interdependency to an absolute minimum
   pg. 495

   Developers, in the other hand, should be application generalists, with knowledge about architecture, development and domain.

This post is part of a set of posts with my personal notes about all the chapters in the book “Domain Driven Design” by Eric Evans. I will do this as I read through the book, and take notes on the concepts I personally find more relevant.