16장 독립성

유스케이스

 

아키텍처는 반드시 유스케이스를 지원해야함.

유스케이스를 통해 행위를 명확히 하고 외부로 드러내며, 시스템이 지닌 의도를 아키텍처 수준에서 알아볼 수 있게 만들어야함.

 

 

 

운영

 

시스템의 운영 지원 관점에서 아키텍처는 더욱 실질적이며 덜 피상적인 역할을 맡음.

예를 들면 유스케이스에 걸맞는 응답시간, 처리량을 보장할 때 이러한 운영 작업을 허용할 수 있는 형태로 아키텍쳐를 구조화 하되 형태는 여러가지로 구조화 될 수 있음. 그러므로 어떤 형태로든 전환할 수 있도록 선택사항을 열어두는것이 좋은 아키텍쳐임.

 

 

 

개발

 

개발시 콘웨이 법칙이 작용함.

 

콘웨이란? 예를들면 한개의 컴파일러를 만드는데 4개의팀이 참여하면 4단계로 빌드해야하는 구조로된다는법칙임.

 

그러므로 각 팀이 서로 방해받지 않으며 독립적으로 행동 하기 편한 아키텍처를 반드시 확보하여함.

 

 

 

배포

 

좋은 아키텍처는 시스템이 빌드된 후 즉각 배포할 수 있도록 지원해야한다.

→ 시스템을 컴포넌트 단위로 적절하게 분할하고 격리시켜야 가능.

 

 

 

선택사항 열어놓기

 

좋은 아키텍처는 선택사항 을 열어 둠으로써, 향후 시스템에 변경이 필요할 때 어떤 방향으로든 쉽게 변경할 수 있도록 함.

 

 

 

계층 결합 분리

 

아키텍트는 SRP, CCP를적용하여 다른 이유로 변경되는 것들을 분리하고, 동일한 이유로 변경되것들을 묶음.

 

 

그림에서는 UI계층은 업무로직계층과 관련이 없기 때문에 수평적으로 분리되어있음.

→ 그러므로 서로 독립적으로 변경이가능함.

 

 

 

유스케이스 결합 분리

 

유스케이스 또한 서로 다른 이유로 변경됨.

 

그림에서는 수평적으로 분리하는 동시에 계층을 가로지르는 수직적인 유스케이스로 시스템이 분할됨.

→ 주문 추가 유스케이스 UI계층과 주문 삭제 유스케이스 UI계층이 분할됨.

→ 이렇게 분리함으로써 기존요소에 지장을 주지않고 새로운 유스케이스를 계속 추가할 수 있음.

→ 또한 유스케이스를 뒷받침하는 UI와 데이터베이스 계층을 서로 묶어서 각 유스케이스가 UI와 데이터베이스의 서로 다른 관점을 사용하게되면 새로운 유스케이스를 계속 추가하더라도 기존 유스케이스에는 영향을 주지 않음. (AOP)

 

 

 

결합 분리 모드

 

그림에서 처럼 결합 분리 작업은 운영 관점에서도 도움이 됨.

→ 유스케이스에서 서로 다른 관점으로 분리되었다면 각 유스케이스 별 처리량에 따른 서로 다른 구조로 설계할 수 있기 때문.

 

 

 

개발 독립성

 

컴포넌트가 완전히 분리되면 각 컴포넌트를 개발하는 팀사이의 간섭은 줄어듬.

→ 예를 들면 업무 규칙이 UI를 알지 못하면 UI를 중점에 둔 팀은 업무 규칙에 중점을 둔 팀에 그다지 영향을 줄 수 없음.

 

 

 

배포 독립성

 

그림에서처럼 유스케이스와 계층의 결합이 분리되면 운영중인 시스템에서도 계층과 유스케이스를 교체(시스템 런타임중 새로운 jar, 서비스 등을 추가하는 일)할 수 있음.

 

 

 

중복

 

중복의 종류로는 진짜 중복, 우발적 중복이 있음.

 

진짜 중복? 한 인스턴스가 변경되면 모든 복사본에도 적용해야함.

우발적 중복? 처음에는 비슷해보이지만 시간이 지나면 서로 다른 방향으로 분기됨.

 

아키텍트는 우발적 중복 여부를 확인하고 통합작업을 신중히 결정하는것이 중요함.

 

 

 

결합 분리 모드(다시)

 

계층과 유스케이스의 결합을 분리하는 방법.

• 소스 수준 분리 모드(모노리틱) : 소스 코드 모듈 사이의 의존성 제어함.
• 배포 수준 분리 모드 : jar 파일과 같이 배포 가능한 단위들 사이의 의존성을 제어함.
• 서비스 수준 분리 모드 : MSA

좋은 아키텍처는

시스템이 모로리틱 구조 → 독립적 배포가능 단위 집합 구조 → 독립적인 서비스 구조로 성장할 수 있도록 만들 수 있어야 함.

또한 거꾸로도 돌릴 수 있어야함.