2부 모델 주도 설계의 기본 요소

소프트웨어를 올바르게 구현하고 모델과의 밀접한 관계를 유지하려면 모델링과 설계의 우수한 실천법들을 적용해야 한다. 도메인 주도 설계 과정을 탄력성 있게 만드려면 잘 알려진 근본 원리들이 Model-Driven Design을 어떻게 뒷받침 하는지 이해해야 한다.

 

우선 아래의 맵을 보고 Model-Driven Design을 뒷받침 하는 요소들을 알아보도록 한다.

 

Model-Driven Design 언어로 구성된 내비게이션 맵

---

도메인의 격리

시스템에서 도메인과 관련이 적은 기능으로부터 도메인 객체를 분리할 필요가 있다.

그렇게 해서 도메인 개념을 다른 소프트웨어 기술에만 관련된 개념과 혼동하거나, 시스템이라는 하나의 큰 덩어리 안에서 도메인을 바라보지 못하는 문제를 방지할 수 있다.

이러한 도메인 객체를 분리하는 정교한 기법에 대해 알아보자

계층형 아키텍처 Layered Architecture

객체지향 프로그램에서는 UI와 DB, 기타 보조적인 성격의 코드각 비즈니스 객체 속에 직접 작성되기도 한다. 그리고 부가적인 업무 로직이 UI 위젯이나 DB 스크립트에 들어가기도 한다.

이러한 코드가 작성되는 이유는 단기적으로 이렇게 작성하는 것이 프로그램을 동작시키는 편한 방법이기 때문이다.

 

도메인에 관련된 코드가 상당량의 도메인과 관련이 없는 다른 코드와 섞여 작성된다면 도메인과 관련된 코드를 확인하고 추론하기가 굉장히 힘들어진다.

예를들면, UI 쪽에 대한 변경이 실제 업무 로직을 변경하게 된다거나, 업무 규칙을 변경하려 할 때 UI 코드나 DB 스크립트 등의 요소들을 세심하게 추적해야 할지 모른다.

 

이는 응집력 있고 모델 주도적인 설계가 되지 못한 프로젝트이고 유지보수, 자동화 테스트가 어려워진다.

기술적인 요소와 업무 로직이 동시에 포함되어 있는 소프트웨어 프로그램을 아주 단순하게 유지하는 것은 정말 중요한데, 때문에 관심사의 분리가 필요하다.

 

계층화에 대한 한가지 핵심 원칙이 있다.

 "한 계층의 모든 요소는 오직 같은 계층에 존재하는 요소나 하위 계층에만 의존한다."

 

위로 올라가는 의사소통은 반드시 간접적인 메커니즘을 거쳐야 한다. (이는 밑에서 간략하게 언급한다.)

 

사용자 인터페이스 (표현 계층)

• 사용자 (혹은 다른 서버 클라이언트)에게 정보를 보여주고 사용자의 명령을 해석하는 일에 대해 책임을 갖는다.

 

응용 계층

• 소프트웨어가 수행할 작업을 정의하고 표현력 있는 도메인 객체가 문제를 해결하게 한다.
• 해당 계층의 책임은 업무상 중요하거나 다른 시스템의 응용 계층과 상호작용하는데 필요한 것들이다.
• 업무 규칙이나 지식이 포함되지 않으며, 오직 작업을 조정하고 아래에 위치한 계층에 포함된 도메인 객체의 협력자에게 작업을 위임한다.
• 업무 상황을 반영하는 상태가 없지만 사용자나 프로그램의 작업에 대한 진행상황을 반영하는 상태는 가질 수 있다.
• 매우 얇게 유지되는 계층이다.

 

도메인 계층 (모델 계층)

• 업무 개념과 업무 상황에 대한 정보, 업무 규칙을 표현하는 일에 대해 책임을 갖는다.
• 업무 상황을 반영하는 상태를 제어하고 사용하며, 그와 같은 상태 저장과 관련된 기술적인 세부사항은 인프라스트럭처에 위임한다.
• 해당 계층이 업무용 소프트웨어의 핵심이다.

 

인프라스트럭처 계층

• 상위 계층을 지원하는 일반화된 기술적 기능을 제공한다.
• 애플리케이션에 대한 메시지 전송, 도메인 영속화, UI에 위젯 그리기 등
• 아키텍처 프레임워크를 통해 4가지 계층에 대한 상호작용 패턴을 지원할 수도 있다.

 

위의 4단계의 계층 분리를 통해 각 계층에서의 책임을 분리하여 프로그램을 단순하게 만들 수 있다.

특히 Model-Driven Design을 가능하게 하는 것은 도메인 계층을 분리한 것에 있다. 표현, 저장, 애플리케이션 작업 관리 등의 책임에서 자유로운 도메인 객체는 도메인 모델을 표현하는 것에만 집중할 수 있고, 이로써 모델은 점점 본질적인 업무 지식을 포착해서 효과를 발휘할 수 있을 만큼 명확하고 풍부해질 것이다.

아래의 설계 원칙을 통해 프로그램을 단순하게 유지시킬 수 있다.

 

1. 여러 개의 계층으로 나눠라
2. 응집력 있고 오직 아래에 위치한 계층에만 의존하는 각 계층에서의 설계를 발전시켜라
3. 표준 아키텍처 패턴에 따라 상위 계층과의 결합을 느슨하게 유지하라
4. 도메인 모델과 관련된 코드는 모두 한 계층에 모으고 사용자 인터페이스, 애플리케이션 코드, 인프라스트럭처 코드와 분리하라

단순화한 온라인 뱅킹 이체에 대한 시퀀스 다이어그램 예제

위 시퀀스 다이어그램에서 각 계층에서 객체들은 자신이 속한 계층의 책임을 수행하고, 동일 계층 혹은 하위 계층에 의존하며, 도메인 계층에서 주요 업무 규칙을 책임지는 것을 발견할 수 있다.

 

계층 간 관계 설정

계층의 분리에 대해 설명했지만 당연하게도 각 계층은 서로 연결되어 있어야 한다. 분리의 장점을 잃지 않으면서 각 계층을 서로 연결하는 것이야 말로 각종 패턴이 존재하는 이유이다.

각 계층은 설계 의존성이 오직 한 방향만으로만(하위 계층 쪽으로) 둬서 느슨하게 결합된다. 상위 계층은 하위 계층의 공개 인터페이스를 호출하고 하위 계층에 대한 참조를 가져 사용하거나 조작한다.

 

하지만 하위 수준의 객체 가 상위 수준의 객체와 소통하려면 다른 메커니즘이 필요한데, 이 때 콜백(callback) 혹은 관찰자 패턴(Observer pattern) 같은 계층 간 관계를 맺어주는 아키텍처 패턴을 활용할 수 있다.

 

응용 계층과 도메인 계층에 UI를 연결하는 패턴도 있다. 익숙히 들어본 MVC 패턴이다. (Movel-View-Controller pattern)

 

지능형 UI (Smart UI) 안티 패턴

위의 그림 (네비게이션 맵)을 보면 Model-Driven Design과 상반되는 상호 배타적인 Smart UI라는 요소가 있다.

오히려 반대되는 패턴에 대해 설명하여 도메인 주도 설계(Domain-Driven Design), 모델 주도 설계(Model-Driven Design)의 필요성에 대해 말하고자 간단히 설명하도록 한다.

 

복잡한 애플리케이션 개발과 Model-Driven Design을 하기로 했다면 해당 패턴은 피하도록 하자

 

장점

• 애플리케이션 단순 경우 생산성이 높고 효과가 즉각적으로 나타난다.
• 다소 능력이 부족한 개발자도 약간의 교육으로 이러한 방식으로 업무 진행이 가능하다.
• 요구사항 분석 단계에서 결함이 발생하더라도 사용자에게 프로토타입을 배포한 후 요구에 맞게 제품을 변경해서 문제를 해결할 수 있다.
• 애플리케이션이 서로 분리되므로 규모가 작은 모듈의 납기 일정을 비교적 정확하게 계획할 수 있다.
• 관계형 데이터베이스와 잘 어울리고 데이터 수준의 통합이 가능하다.
• 애플리케이션을 인도했을 때 유지보수 개발자가 이해하지 못하는 부분을 신속하게 재작업할 수 있다. 변경의 효과가 특정 UI에만 국한되기 때문이다.

단점

• DB를 이용하는 방식 말고는 여러 애플리케이션을 통합하기 어렵다.
• 행위를 재사용하지 않으며 업무 문제에 대한 추상화가 이뤄지지 않는다. 업무 규칙이 적용되는 연산마다 중복된다.
• 신속한 프로토타입 작성과 반복주기가 Smart UI가 지닌 태생적인 한계에 도달하게 된다.
  (추상화 부재로 인한 리팩토링의 여지가 제한되기 때문)
• 복잡성에 금방 압도되어 애플리케이션의 성장 경로가 순전히 부가적인 단순 응용으로만 향한다.

 

 

 

 

다음글 : 2021.03.15 - [Domain Driven Design] - 2부. 소프트웨어에서 표현되는 모델 : 연관 관계(association)

2부 모델 주도 설계의 기본 요소 - 표현 모델 (연관관계)