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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s