5부. 아키텍처

17장. 경계: 선 긋기

경계

• 경계는 한편에 있는 요소가 반대편에 있는 요소를 알지 못하도록 막는다.
• 프로젝트 초기에 작성되는 경우도 있고, 매우 나중에 그어지는 경우도 있다.
• 초기에 경계를 긋는 경우는 왜 초기에 긋는가?
  • 가능한 한 결정을 오랫동안 연기시키기 위해. 즉, 핵심적인 업무 로직을 오염시키지 못하게 만들려는 목적
  • 왜 경계를 그어야하는가..?
    • 시스템의 업무 요구사항과 관련없는 결정에 따른 결합은 생산성을 떨어트리기 때문. (프레임워크, DB, 웹서버, 유틸리티 라이브러리, 의존성 주입 등에 대한 결정)
    • 좋은 아키텍처는 이러한 결정에 의존하지 않는다.

좋은 사례

Fitnesse 의 위키 페이지 만들 기

잘한점: 어떤 Database를 사용할 것인지를 미뤄둠.

어떤 DB를 사용하더라도 상관없는 형태로 설계함으로써 의도적으로 DB에 대한 결정을 미루었다.

• 어떻게: 모든 데이터 접근 영역과 데이터저장소 영역 사이에 인터페이스 추가. (다형성, DIP)
• 개발도중: DB가 없으므로 인터페이스의 구현체는 Stub 으로 만들었다.
• 구현체 1: DB가 아닌 메모리에 저장하도록 함.
• 구현체 2: 영속성을 위해 MySql을 사용함. 하루만에 MySql 구현체를 추가했음.

Fitnesse 는 어떤 경계를 그었는가? => 업무 규칙과 데이터베이스 사이에 경계선(Boundary Line)을 그었다.

경계선을 긋는 행위는 결정을 늦추고 연기하는 데 도움이 되었고, 궁극적으로는 시간을 엄청나게 절약해주었다. => 결국 결정을 미루기 위한 구체적인 방법 중 하나가 경계를 긋는 것이군..

언제, 어떻게 선을 그을까?

관련이 있는 것과 없는 것 사이에 선을 긋는다.

eg) GUI는 업무규칙과 관련이 없기 때문에, 둘 사이에 선을 긋는다. eg) GUI는 DB와 관련이 없기 때문에, 둘 사이에 선을 긋는다. eg) DB는 업무규칙과 관련이 없기 때문에, 둘 사이에 선을 긋는다. (Fitnesse 와 동일)

업무규칙과 DB ||| |:–:|:–:|

업무 규칙이 DB에 의존하지 않게 선을 그었기 때문에 DB에 대한 결정을 미룰 수 있는 것 같다. Onion Architecture 가 떠오른다..

업무규칙과 GUI UX(사용자 경험) 는 인터페이스(화면,마우스,음향)에 의해 좌우된다고 생각하여 중요하다고 생각할 수 있겠지만, 중요한 것은 업무규칙이다.

결국 플러그인 형태다.

플러그인 형태는 손쉽게 생성하고 확장가능하고 유지보수가 쉽다.
선택적이거나 다양한 형태로 구현될 수 있는 나머지 컴포넌트로부터 핵심적인 업뮤 규칙은 분리되어있고, 독립적이다.

결론

경계선을 그리려면?

1. 시스템을 컴포넌트 단위로 분할
2. 컴포넌트 사이의 화살표가 핵심업무를 향하도록 컴포넌트 소스를 배치
   • 고수준 추상화를 위해 DIP, SDP를 활용한다.