caffeine-library/Domain-Driven-Design

[keyword] 16장 대규모 구조 (1)

Closed this issue · 1 comments

주제

'16장 - 대규모 구조 (1)'을 읽고 내용을 요약하거나,
중요✨ 하다고 생각하는 키워드 및 관련 설명을 코멘트로 달아주세요

연관 챕터

#64

목적

전체적인 관점에서 해당 부분의 위치를 어느 정도 이해하는데 도움을 주는 규칙 또는 규칙과 관계의 패턴을 고안 (전체적으로 적용되는 규칙)

  • 모듈화라는 게 반드시 설계에 균일함을 가져오는 것은 아님
  • 큰 그림에 대한 개념을 공유하여 독립적인 업무를 조율하는 태도를 형성

전체 시스템에 일관성과 맥락을 부여하는 것과 유사

EVOLVING ORDER : 구조를 발전하고 정제하는데 활용

  • 대규모 구조가 부자연스러운 제약 조건을 강제하지 않고 시스템을 명확하게 만드는 것으로 판명될 때만 적용되어야 함
  • 대규모 구조가 어플리케이션과 함께 발전할 때 전혀 다른 구조로도 변화할 수 있게 해야함 (유연성)
    • 예외는 손쉽게 파악할 수 있게 하되, 예외가 많아지면 구조를 변경하거나 폐기해야 한다

SYSTEM METAPHOR: 사고를 이끄는 수단으로 활용

  • 소프트웨어 설계는 추상적이기 때문에, 개발자와 사용자 모두 시스템을 이해하고 바라보는 시각을 공유할 구체적인 수단이 필요
  • 구체적인 은유가 발생하여 팀원의 상상력을 포착하고 유용한 방향으로 사고를 이끄는 것으로 보이면 대규모 구조로 채택

RESPONSIBILITY LAYER : 계층화의 대상으로 활용

  • 도메인에 자연적인 계층이 식별되면 이걸 광범위한 추상적인 책임으로 간주 (고수준에서의 목적과 설계를 얘기해줌)
    • 각 도메인 객체의 책임이 한 계층의 책임 안에서 말끔히 맞아 떨어지도록 모델을 리팩터링
    • RELAXED LAYERED : 한 계층의 구성요소가 바로 아래에 있는것 말고도 모든 하위 계층에 접근
  • 잠재 기능, 운영, 의사결정 지원, 정책, 계약 이라는 다섯개의 추상화된 책임 계층에 대한 예시

(p. 485) 사용자의 용도를 고려해 봤을 때 Customer 는 잠재 계층에 속한다. 보다시피 이것은 기술적인 결정에 속하지 않는다. 이는 도메인의 지식을 포착하고 전달하려는 시도에 해당한다.