15, 16장 요약

좋은 아키텍쳐란, 선택사항을 최대한 오랫동안 열어두는 것. 이것이 곧 소프트웨어를 유연하고 부드럽게 만들어주는 핵심이다.

17장 - 경계: 선 긋기

3줄 요약

소프트웨어 아키텍쳐는 선을 긋는(경계를 짓는) 기술. 선의 역할은 세부사항들(유스케이스와 아무런 관련이 없는 데이터베이스, 프레임워크 등)에 대한 결정을 가능한 한 오랫동안 연기시켜 핵심 업무 로직에 집중하고 인적 자원의 효율성을 늘리기 위한 것.

위 내용을 전달하기 위한 두가지의 실패 사례와 한가지의 성공 사례

• 실패 사례 1: “GUI - 미들웨어 서버 - 데이터베이스” 로 이루어진 3-티어로 구성된 “아키텍쳐”(책에서는 이는 아키텍쳐가 아닌 topology라 설명)를 너무나 이르게 결정함. 하지만 결국에는 단일 서버만을 배포함으로서 개발 비용을 엄청나게 가중시킨 실패 사례
• 실패 사례 2: “서비스 지향 아키텍쳐(MSA)”를 너무나 빠르게 결정함으로서 엄청난 인적 시간에 따른 비용이 발생한 실패 사례
• 성공 사례 1: “데이터베이스”에 대한 결정을 오랫동안 미루고 인터페이스만 구성하여 다양한 좋은 방법들을 시도해보고 더 나은 해결책을 모색할 수 있었음. 더군다나 중간에 고객이 MySQL로 데이터베이스를 구성할 수 있도록 요청했음에도 플러그인 상태로 구현하여 빠르게 동작할 수 있도록 했음. 이러한 결정 미루기는 시간과 인적 비용을 상당히 절약 시켜주었음(작가의 경험담)

그렇다면 선은 언제, 어떻게 긋나?

서로 관련이 없는 것들 사이에 선을 그어라. 업무 로직과 데이터베이스를 예로 들었을 때*(그림 17.1 참고), 데이터베이스를 직접적으로 조작하는 Database Access(Genny로 따지면 repository)와 Business Rules 사이에 선을 그어야 한다. 선을 긋는 방법은 Database interface(고수준)를 만들어 Business Rules 쪽으로 두고, Business Rules와 Database Access는 이를 의존하도록 한다(그림 17.2 참고)*. 즉, 항상 저수준이 고수준을 향하도록 만들어 Business Rules는 Database의 존재를 모르도록 하는 것이 핵심이다. 이렇게 함으로서 데이터베이스에 대한 결정(MongoDB를 쓸지, MySQL을 쓸지)을 미룰 수 있도록 하여 업무 로직에만 집중할 수 있다. (업무로직과 GUI도 이와 같다)

결론

핵심 업무로직과 필수기능이지만 나중에 정해도 되는 세부 사항들 사이에 선을 긋고, 세부 사항들이 핵심 로직을 향할 수 있도록 배치한다. 즉, 핵심 업무 로직이 세부 사항들을 언제든지 꼈다 뺄 수 있는 플러그인 형태로 아키텍쳐를 구성하자.