Closed y2o2u2n closed 2 years ago
개념적인 대규모 구조를 애플리케이션 발전 과정에서 다른 형식의 구조로도 변화할 수 있게 만들어라
세부 설계 및 모델을 과도하게 제약해서는 안된다 (개별 부분에 전역적인 규칙을 적절하게 타협하여 적용)
구조 및 규칙들을 코드 저장소에 문서화 (CONVENTION.md)
추상적이고 파악하기 힘든 소프트웨어를 이해하고 시스템을 전체적으로 바라보는 시각을 공유할 수단 시스템의 구체적인 비유가 나타나면 그것을 대규모 구조로 채택, 중심으로 설계를 구성, UL 로 흡수
RELAXED LAYERED SYSTEM: 한 계층의 구성요소가 바로 아래 + 모든 하위 계층에 접근 허용
개념적 의존성과 도메인의 변화율, 변화의 근본을 검토
도메인에서 자연적인 층을 추상적인 책임으로 간주
AGGREGATE, MODULE 등의 도메인 객체의 책임이 한 계층의 책임 안에 있도록
예제를 보니 도메인에 대한 계층 그림이 잘 관리가 되어야 기능 추가할 때도 생각하기가 편할 것 같다
다른 객체 집단이 어떻게 행동해야 하는지를 기술하는 객체 그룹
REFLECTION 패턴의 도메인 계층을 응용한 것 - 소프트웨어를 self-aware 하게 만듦
base level (운영적 책임), meta level (구조와 행위에 대한 지식)
언어의 reflection 은 도메인을 위한 것이 아님 - 해당 언어 구성물 자체의 구조와 행위
KNOWLEDGE LEVEL 은 반드시 일반 객체로 만들어야 함
애플리케이션의 도메인에 초점 + 완전한 보편성을 달성하진 않음
모델의 구조와 행위를 서술하고 제약하는 데 쓸 수 있는 별도의 객체 집합을 만드는데
하나는 매우 구체적으로, 하나는 사용자/관리자의 맞춤화가 가능한 규칙과 지식을 반영하게
그냥 도메인하고 무슨 차이지???? ❓
interface 와 interaction 에 대한 abstract core 를 만들어 구현이 자유롭게 대체될 수 있는 프레임워크를 만들어라
구조적 규칙은 개발을 용이하게 해야 한다
초반엔 SYSTEM METHPHOR, RESPONSIBILITY LAYER 정도
팀 전체가 구조를 이해하고 따라야 함. 용어와 관계는 반드시 UL 에 대화를 UL 에 통합하여 끊임없이 연습하게 만들어야 함
구조가 바뀔 때마다 전체 시스템을 새로운 질서에 맞게 바꾸기
어렵다..
RESPONSIBILITY LAYER 에서,,
의사결정 지원계층은 운영 sw와 customer/supplier 관계를 맺은 별도의 BC가 된다.
그럼 의존하고있는 하위계층은 같은 BC로 묶이는건가? 운영 SW라는게 운영계층을 의미하는건지 booking application을 의미하는건지..
예상하는 분류??
모델을 대상으로 계층을 분리해서, 책임(중요도)를 구별한다.
이거 하는 이유가????????
참고 사이트
대규모 구조
전체의 세부 사항을 깊이 파고 들지 않고도 전체의 각 부분이 담당하는 역할을 이해할 수 있도록 돕는 언어
EVOLVING ORDER
SYSTEM METAPHOR
RESPONSIBILITY LAYER
KNOWLEDGE LEVEL
PLUGGABLE COMPONENT FRAMEWORK
그 외