도메인 주도 설계 - 4. 도메인의 격리

본 내용은 에릭 에반스의 도메인 주도 설계를 공부하면서 제 나름대로 이해하기 쉽게 정리한 글입니다.

이해가 어려우시다면 댓글 부탁드립니다.

---

LAYERED ARCHITECTURE(계층형 아키텍처)

 도메인코드가 도메인과 관련이 없는 다른 코드와 같이 섞일 경우 도메인 코드를 이해하기가 굉장히 힘들어진다. 도메인 코드와 UI가 같이 섞일 수 경우 UI를 변경하는 것이 실직적으로 업무 로직을 변경하는 것으로 이어질 수 있다.  

 

복잡한 소프트웨어의 경우 관심사의 분리가 필요하다.

 

 소프트웨어 시스템을 분리하는 방법 중에 하나인 LAYERED ARCHITECTURE는 널리 사용되고 있다.  LAYERED ARCHITECTURE는 몇개의 일반화된 계층으로 나눈 방법이다. 한 계층의 모든 요소는 오직 같은 계층에 존재하는 요소나 계층상 아래에 위치한 요소에만 의존한다는 원칙이 있다.

 

일반적인 LAYERED ARCHITECTURE의 계층 구성

사용자 인터페이스	사용자에게 정보를 보여주고 사용자의 명령을 해석하는 일을 담당
응용 계층	소프트웨어가 수행할 작업을 정의하고 표현력 있는 도메인 객체가 문제를 해결하게 위임하는 작업. 업무상 중요하거나 다르 시스템의 응용 계층과 상호작용하는 작업을 책임짐 여기에는 업무 규칙이나 지식이 포함되어 있지 않음.
도메인 계층	업무 개념과 업무 상황에 관한 정보, 업무 규칙을 표현하는 일을 책임짐
인프라스트럭처 계층	상위 계층을 지원하는 일반화된 기술적 기능을 제공. 도메인 영속화이 대표적. 또한 인스라스트럭처 계층은 아키텍처 프레임워크를 통해 이 LAYERED ARCHITECTURE 패턴을 지원할 수도 있음

 

복잡한 프로그램을 여러 개의 계층으로 나누는 것은 중요하다. 응집력있고 오직 아래에 있는 계층에만 의존하는 방식으로 각 계층에서 설계를 발전시켜야 한다 도메인 모델과 관련된 코드는 모두 한 계층에 모으고 다른 코드와 격리 시켜야 한다. 그래야 도메인 모델을 표현하는 것에만 집중할 수가 있다.

계층간 관계

각 계층은 의존성을 한 방향으로만 둬서 느슨하게 결합된다. 상위 계층은 하위 계층과 동일한 계층의 공개 인터페이스를 호출하고 참조한다. 하위 객체가 상위 계층과 소통해야할 경우 콜백(callback)이나 OBSERVER(관찰자) 패턴을 고려해볼 수 있다.

 

SMART UI(지능형 UI) "안티 패턴"

도메인 주도 설계 접근법과 완전히 다른 접근법이다. 

 모든 업무 로직을 사용자 인터페이스에 넣는 패턴이다. 애플리케이션을 작은 기능으로 나누고 나눈 기능을 UI로 구현해서 업무 로직을 나눈 UI에 들어가게 한다. 이러한 SMART UI는 도메인 주도 설계 맥락에서는 안티 패턴으로 간주된다. 특정한 상황에서는 적합할 수도 있다.

장점

• 애플리케이션이 단순한 경우 생산성이 높고 효과가 즉각적이다.
• 배우기 쉽다.
• 요구사항 분석 단계에서 결함이 생기더라도 사용자에게 프로토타입을 배포한 후 요구사항에 맞게 변경해서 문제를 해결할 수 있다.
• 관계형 데이터베이스와 잘 아울리고 데이터 수준의 통합이 가능하다.
• 4세대 언어와 잘 어울린다.
• 빠르게 유지보수가 가능하다.

단점

• 데이터베이스 이용하는 방식 말고는 여러 애플리케이션을 통합하기가 어렵다.
• 행위를 재사용하지 않고 업무 문제에 대핸 추상화가 이뤄지지 않는다. 업무 규칙이 중복된다.
• 추상화의 부재로 리팩터링이 제한된다.
• 복잡성이 압도되어 애플리케이션 성장 경로가 막힌다. 풍부한 행위를 갖출 수 없다.