경계:선긋기

1.경계

• 소프트웨어 아키텍처는 선을 긋는 기술이며, 이러한 선을 경계(boundary)라고 하자.
• 프로젝트 초기에 만들어진 경계는 가능한 한 오랫동안 결정을 연기시키기 위해, 그래서 이들 결정이 핵심적인 업무 로직을 오염시키지 못하게 만들려는 목적으로 쓰인다.
  • 프레임워크, 데이터베이스, 웹서버, 유틸리티 라이브러리, 의존성 주입에 대한 결정등은 유스케이스와 아무런 관련이 없는 결정이다.
  • 좋은 아키텍처란 이러한 부수적인 요소들에 의존하지 않고, 최대한 결정을 지연시킬 수 있는 선을 긋는 것이다.

2.어떻게, 언제 선을 그을 것인가

• 관련이 있는 것과 없는 것 사이에 선을 긋는다. → GUI / 업무규칙 / 데이터베이스 사이에 선을 그어야 한다.
• 먼저 업무규칙과 데이터베이스 관계를 살펴보자.

이미지 출처 : https://hwannny.tistory.com/36

• 그림에서 경계선은 Interface, Database Access사이에 그어짐.
• Database Access를 알고있는 클래스는 없음.
• Business Rules 컴포넌트안에 Database Interface를 Database 컴포넌트 내부의 Database Access가 의존하고있음.

이미지 출처 : https://hwannny.tistory.com/36

• 컴포넌트 관점에서 살펴보자.
  • Business Rules 컴포넌트에게 있어 Database 컴포넌트는 문제가 되지않음, 그러나 Business Rules 컴포넌트의 호출을 쿼리언어로 변환하는 코드를 Database 컴포넌트가 담고 있기 때문에 Database 컴포넌트는 Business Rules 컴포넌트 없이 존재할 수 없음.
  • 화살표 방향은 Business Rules 컴포넌트를 향하고있기 때문에 Business Rules 입장에선 Database 컴포넌트는 다른 구현체로도 교체될 수 있음.
    • 데이터베이스에 대한 결정 연기가능.
    • 업무규칙 작성, 테스트에 집중 가능.

3.입력과 출력은?

• 입출력 행위를 보여주는 사용자 인터페이스(GUI) 뒤에는 실제로 그 인터페이스를 조작하는 모델이 있다.
• 사용자 인터페이스는 모델에 의존하지만, 모델은 인터페이스 존재를 알지 못한다.
• 모델은 다만 비지니스 룰에 따라 모델링을 진행할 뿐이다.
• 따라서 GUI 관계와 비지니스 룰의 관계도 아래와 같이 표현할 수 있다.

4.플러그인 아키텍처

• 2,3번 내용을 종합해보면 아래 그림이 나온다.

• 플러그인 형태를 고려하면 이러한 그림이 나오게 된다.
• 선택적이거나 또는 수많은 다양한 형태로 구현될 수 있는 나머지 컴포넌트(DB, GUI)로부터 핵심적인 업무 규칙은 분리되어 있고, 또한 독립적이다.