• 대규모 구조의 기법을 여러 개 적용한다면?
• 대규모 구조는 어떻게 CONTEXT MAP과 공존하는가?
• 전략의 우선 순위, 순서?

전략적 설계의 세가지 원칙(컨텍스트, 디스틸레이션, 대규모 구조)은 서로 대체 가능하지 않다. 그것들은 여러 가지 면에서 서로 보완하며 상호작용한다.

RESPONSIBILITY LAYER를 도입하고 싶지만
원하는 대규모 구조와 구성이 맞지 않는 레거시 시스템이 있다고 가정할 때,
레거시 시스템의 범위의 역할의 핵심 측면을 연결지을 수 있다.
이 때, ANTICORRUPTION LAYER 기법을 사용하여 질의/번역을 통해 각 서비스를 연결할 수 있고,
CONTEXT 안에서 똑같이 익숙한 LAYER를 기준으로 CONTEXT MAP을 구성하여 모델을 정리할수도 있다.

대규모 구조는
CORE DOMAIN 안의 각종 관계와 여러 GENERIC SUBDOMAIN 사이의 관계를 설명하는 데 도움될 수 있다.
동시에 대규모 구조 자체도 CORE DOMAIN의 중요한 부분일지도 모른다.

프로젝트에 대한 전략적 설계를 다룰 때는
현 상황을 명확하게 평가하는 일부터 시작해야 한다.

1. CONTEXT MAP을 그려라. 일관된 CONTEXT MAP을 그릴 수 있는가? 그렇지 않다면 모호한 상황이 있는가?
2. 프로젝트상의 언어를 쓰는 데 힘써라. UBIQUITOUS LANGUAGE가 있는가? UBIQUITOUS LANGUAGE가 개발에 도움을 줄 만큼 풍부한가?
3. 무엇이 중요한지 이해하라. CONTEXT DOMAIN을 식별했는가? DOMAIN VISION STATEMENT가 있는가? DOMAIN VISION STATEMENT를 작성할 수 있는가?
4. 프로젝트에 사용하는 기술이 MODEL-DRIVEN DESIGN에 유리한가, 불리한가?
5. 팀 내 개발자가 필요한 기술 역량을 갖췄는가?
6. 개발자들이 도메인을 잘 알고 있는가? 개발자들이 도메인에 관심이 있는가?

Emergent Structure from Application Development

의사소통 능력이 출중한 사람으로 구성된, 자기훈련을 행하는 팀.

XP 팀의 전형적인 모델.
비공식적인 리더가 실천적인 개발자일 때 효과적.

다양한 애플리케이션 팀과 함께 동등한 위치에서
개발자들과 함께 패턴을 발견하고 디스틸레이션에 도달하고자
다양한 팀과 실험하면서 직접 궂은 일에 나서는,
개발의 진정한 협력자에 해당한다.

• 의사결정은 팀 전체에 퍼져야 한다
• 의사결정 프로세스는 피드백을 흡수해야 한다.
• 계획은 발전을 감안해야 한다. 프로젝트 도중 직면한 문제를 해결할 수 있도록 제약에 유연해야 한다.
• 아키텍처 팀에서 가장 뛰어나고 똑똑한 사람들을 모두 데려가서는 안 된다.
  • 모든 애플리케이션 팀에는 반드시 능력이 출중한 설계자가 포함돼 있어야 한다. 기술적인, 설계적 정교함이 가장 부족한 개발자가 애플리케이션을 구축하게 내버려두지 마라.
  • 전략적 설계를 시도하는 모든 팀은 반드시 도메인 지식을 겸비해야 한다. 깊이 있는 도메인 지식을 지닌 개발자를 팀에서 떨어져 나가게 하면 아키텍트의 노력이 훨씬 더 곤경에 처할 것이다.
• 전략적 설계에는 최소주의와 겸손이 필요하다.
  • 겸손 : 나의 가장 좋은 생각이 누군가에게는 방해가 되리라는 사실을 깨닫는 것
• 객체는 전문가, 개발자는 다방면에 지식이 풍부한 사람 (Objects are specialists; developers are generalists)
  • 간혹 우리는팀 간의 상호작용을 소프트웨어의 상호작용만큼 잘 정돈된 상태로 만들려고 한다. 좋은 프로젝트에서는 많은 사람들이 다른 사람의 업무에 참견한다.
  • OOP 설계에 비유해서) 객체를 전문가로 만들고, 개발자들은 다방면에 지식이 풍부한 사람이 되게 하라. (Make the objects into specialists; let the developers be generalists)

The Same Goes for the Technical Frameworks

아키텍처가 도메인 모델에대한 표현력있는 구현과 손쉬운 변경을 방해할 수 있는 프레임워크에 경계하라.

• 설계를 못하는 개발자들을 소프트웨어 개발 부서에 배정해서는 안된다.
  • 이에 대척하는 팀과 장벽이 생겨 갈등을 조장한다. 이러한 태도는 팀간의 관계에도 악영향을 미친다.
    • 프레임워크 설계자가 해당 프레임워크 사용자를 존중하는 듯하다면 그 설계자는 아마 올바른 길로 가고 있을 것이다.

Beware the Master Plan

점진적 성장에 초점을 맞춰라.
지나친 제약은 예측 불가능한 변화에 유연하지 못하다.

  그러므로 유기적인 질서의 일환에 해당하는 종합계획은
  너무 정확하면서 동시에 충분히 정확하지 못하다.
  
  전체성은
  너무 정확하지만 세부사항은 충분히 정확하지 못한다.