Large Scale Structure : 대규모 구조

큰 시스템에서 해당 시스템의 요소를 전체 설계에 걸친 패턴에서의 "역할" 측면에서 해석하게 할 수 있는 지배적인 원칙이 없다면 개발자들은 나무만 보고 숲을 보지 못한다. 우리는 전체의 세부 사항을 깊이 파고들지 않고도 전체의 각 부분이 담당하는 역할을 이해할 수 있어야 한다. 때문에 전체 시스템을 포괄하고 각 부분의 책임을 자세히 알지 못해도 전체적인 관점에서 해당 부분의 위치를 어느 정도 이해하는데 도움을 주는 규칙이나 관계의 패턴을 고안해야 한다.

---

• Evolving Order : 발전하는 질서

  • 프로젝트에서는 다양한 방법으로 개발을 제약하는 Architecture가 적용되는데 이런 Architecture가 Application과 Doamin까지 내려간다면 해당 아키텍처만의 문제가 발생할 수 있다.
  • 개념적인 대규모 구조가 Application과 함께 발전하게 해서 발전 과정에서 다른 형식의 구조로도 변화할 수 있어야 한다. 때문에 세부적인 설계, 모델과 관련된 의사결정을 과도하게 제약해서는 안된다.
  • 대규모 구조는 어떤 구조가 Model을 개발하는데 부자연스러운 제약조건을 강제하지 않고도 시스템을 명확하게 만드는 것으로 판명될 때 적용해야 한다.

• System Metaphor

  • 소프트웨어 설계는 매우 추상적이고 파악하기 힘든 경향이 있기 때문에 개발자와 사용자 모두 시스템을 이해하고 시스템을 전체적으로 바라보는 시각을 공유할 구체적인 수단이 필요하다.
  • Domain에 대한 은유와 비유이다.
  • 여러 Bounded Context에 적용되어 서로의 Business를 조율하는데 도움을 줄 수 있다.
  • 부정확하거나 방해가 될 수 있으므로 언제든지 버릴 수 있다.

• Responsibility Layer

  • 넓은 범위의 추상적인 책임을 Layer 단위로 구분하여 할당한다.
  • Module과 Aggreate를 설계할 때 범위를 특정 Layer로 고정하면 책임을 더 쉽게 파악할 수 있다.
  • 고수준의 책임과 Layer를 결합하면 시스템의 구성 원칙을 확보할 수 있다.
  • 상위 Layer에서 하위 Layer로 단방향으로만 접근할 수 있다.

  • 

  • 

• Knowledge Level

  • 

  • Model의 구조와 행위를 서술하고 제약하는 데 사용할 수 있는 별도의 개체 집합을 만든다. 이러한 관심사를 두 가지 수준으로 분리하여 하나는 매우 구체적으로 만들고, 다른 하나는 사용자나 관리자의 맞춤화가 가능한 규칙과 지식을 반영하게 만든다.

  • 

  • ---------------------------------------------------------------------------------------------------------------------

    

• Pluggable Component Framework

  • Interface와 상호작용에 대한 Abstract Core를 정제하고 다양한 구현이 자유롭게 대체될 수 있는 프레임워크를 만든다. Component는 Abstract Core의 Interface를 통해 정확히 동작하고, Application에서도 Component를 사용할 수 있어야 한다.

  •