LAYERED ARCHITECTURE
우리는 시스템에서 도메인과 관련이 적은 기능으로부터 도메인 객체를 분리할 필요가 있다. 도메인의 격리는 도메인 지식을 그와 상관이 없는 기술적인 부분과 혼동하거나, 애플리케이션에서
도메인 지식이 흐려지는 것을 방지할 수 있다.
얼마 전 공부했던 클린 아키텍쳐 또한 layered architecture의 일종으로 볼 수 있으며, 이러한 아키텍쳐의 근본적인 목적은 도메인의 격리이다.
사용자 인터페이스 (User Interface) 계층
사용자에게 정보를 보여주고 사용자의 명령을 해석하는 일을 책임진다. 우리가 만들 어플리케이션을 백엔드로 한정한다면, 이는 리퀘스트의 첫 진입점인 Controller에 대응될 것이다.
응용 (Application) 계층
소프트웨어가 수행할 작업을 정의하고 표현력 있는 도메인 객체가 문제를 해결하게 한다. 이 계층에서 책임지는 작업은 업무상 중요하거나 다른 시스템의 응용 계층과 상호작용하는 데 필요한 것들이다.
소프트웨어가 실제로 수행할 작업에 대한 정의는 이 계층에서 이루어지지만, 어떠한 비즈니스 로직이나 도메인 지식도 포함되지 않는다. 이들에 대한 처리는 모두 도메인 계층의 책임이다.
도메인 (Domain) 계층
업무 개념과 업무 상황에 관한 정보, 업무 규칙을 표현하는 일을 책임진다. 바로 이 계층에 개발자와 도메인 전문가가 함께 고민한 도메인 지식이 담긴다. 이 계층에서는 업무 상황을 반영하는 상태를 제어하고 사용하며, 그와 같은 상태 저장과 관련된 기술적인 세부사항은
인프라스트럭처에 위임한다. 이 계층은 업무용 소프트웨어의 핵심이다.
인프라스트럭처 (Infrastructure) 계층
위에서 언급한 상위 계층을 지원하는 일반화된 기술적 기능을 제공한다.
SMART UI "안티 패턴"
스마트 UI는 위에서 설명한 UI 계층에 모든 업무 로직이 담기는 아키텍쳐를 뜻한다. 이러한 아키텍쳐도 그 나름의 장점이 있지만, 이 책에서 설명하는 도메인 주도 설계와는 배타적인
설계 방법이기 때문에 어느 상황에서 이 아키텍쳐를 써도 되는지, 혹은 쓰면 안되는지 알아둘 필요가 있다.
장점
- 애플리케이션이 단순한 경우 생산성이 높고 효과가 즉각적으로 나타난다.
- 러닝커브가 가파르지 않다.
- 요구사항 분석 단계에서 결함이 발생하더라도 사용자에게 프로토타입을 배포한 후 요구에 맞게 제품을 변경해서 문제를 해결할 수 있다.
- 애플리케이션이 서로 분리되므로 납기 일정을 비교적 정확하게 계획할 수 있다.
- 4세대 언어 도구와 잘 어울린다.
단점
- 행위를 재사용하지 않으며 업무 문제에 대한 추상화가 이루어지지 않는다. 업무 규칙이 적용되는 연산마다 업무 규칙이 중복된다.
- 신속한 프로토타입 작성과 반복주기가 태생적인 한계에 도달하게 된다. 이는 추상화의 부재로 리팩터링의 여지가 제한되기 때문이다.
- 복잡성에 금방 압도되어 애플리케이션의 성장 경로가 순전히 부가적인 단순 응용으로만 향한다. 우아한 방법으로 더욱 풍부한 행위를 갖출 수 있는 방법은 없다.
현재 내가 속한 회사는 전형적인 SMART UI 패턴을 따르고 있는 듯 하다. 회사에서 개발을 하면서 많은 불만과 답답함을 느꼈지만 문제를 명확하게 규명하거나 확실한 대안을 찾을 수 없었는데,
이 부분의 글을 읽으면서 현재 처해 있는 문제 상황을 좀 더 정확하게 바라볼 수 있게 된 것 같다.
