결합분리

만약, 아키텍트가 있다면, 업무 분담을 어떻게할까? 어떻게 분리할까?

1. 계층

2. 유스케이스

계층 결합 분리

아키텍트는 필요한 모든 유스케이스를 지원할 수 있는 시스템 구조를 원함. 하지만 유스케이스 전부를 알지는 못함. 하지만 시스템의 기본적인 의도는 분명히 알고 있음. 그게 장바구니인지, 자재 명세서인지, 주문처리인지 등등. 따라서 아키텍트는 단일 책임 원칙과 공통 폐쇄 원칙을 적용항 

다른 이유로 변경되는 것들은 분리하고,

동일한 이유로 변경되는 것들은 묶어야함.

 

서로 다른 이유로 변경되는 건 뭘까?

UI가 변경되는 이유는 업무 규칙과는 아무런 관련이 없다.

뛰어난 아키텍트는 UI부분과 업무 규칙 부분을 서로 분리하고자 할 것임.

 

즉 아키텍트는 이들을 분리해야함.

 

수평적인 계층으로 분리하는 방법을 알게되었음. 

즉

UI,

애플리케이션에 특화된 업무 규칙

애플리케이션에 독립적인 업무 규칙

데이터베이스

 

유스케이스 결합 분리

유스케이스는 시스템을 분할하는 매우 자연스러운 방법임. (추가와 삭제는 다른 연산이기 때문에), 수직으로 좁다란 조각임. 수직과 수평을 분할할 수 있음. 이말은 UI도 분리해야된다는 말. 즉 유스케이스는 겹치면 안됨.

즉 새로운 유스케이스를 지속해서 추가 가능함.

- 기존 유스케이스에