[keyword] 16장 대규모 구조 (1)
Closed this issue · 1 comments
kth990303 commented
emiling commented
목적
전체적인 관점에서 해당 부분의 위치를 어느 정도 이해하는데 도움을 주는 규칙 또는 규칙과 관계의 패턴을 고안 (전체적으로 적용되는 규칙)
- 모듈화라는 게 반드시 설계에 균일함을 가져오는 것은 아님
- 큰 그림에 대한 개념을 공유하여 독립적인 업무를 조율하는 태도를 형성
전체 시스템에 일관성과 맥락을 부여하는 것과 유사
EVOLVING ORDER : 구조를 발전하고 정제하는데 활용
- 대규모 구조가 부자연스러운 제약 조건을 강제하지 않고 시스템을 명확하게 만드는 것으로 판명될 때만 적용되어야 함
- 대규모 구조가 어플리케이션과 함께 발전할 때 전혀 다른 구조로도 변화할 수 있게 해야함 (유연성)
- 예외는 손쉽게 파악할 수 있게 하되, 예외가 많아지면 구조를 변경하거나 폐기해야 한다
SYSTEM METAPHOR: 사고를 이끄는 수단으로 활용
- 소프트웨어 설계는 추상적이기 때문에, 개발자와 사용자 모두 시스템을 이해하고 바라보는 시각을 공유할 구체적인 수단이 필요
- 구체적인 은유가 발생하여 팀원의 상상력을 포착하고 유용한 방향으로 사고를 이끄는 것으로 보이면 대규모 구조로 채택
RESPONSIBILITY LAYER : 계층화의 대상으로 활용
- 도메인에 자연적인 계층이 식별되면 이걸 광범위한 추상적인 책임으로 간주 (고수준에서의 목적과 설계를 얘기해줌)
- 각 도메인 객체의 책임이 한 계층의 책임 안에서 말끔히 맞아 떨어지도록 모델을 리팩터링
- RELAXED LAYERED : 한 계층의 구성요소가 바로 아래에 있는것 말고도 모든 하위 계층에 접근
- 잠재 기능, 운영, 의사결정 지원, 정책, 계약 이라는 다섯개의 추상화된 책임 계층에 대한 예시
(p. 485) 사용자의 용도를 고려해 봤을 때 Customer 는 잠재 계층에 속한다. 보다시피 이것은 기술적인 결정에 속하지 않는다. 이는 도메인의 지식을 포착하고 전달하려는 시도에 해당한다.