도메인의 격리
소프트웨어 시스템에서 도메인 문제를 해결하는 부분은 전체 시스템에서 작은 부분을 차지하지만, 그 중요성은 매우 큽니다.
모델 요소들을 시스템으로 보고, 다른 객체들 속에서 찾아내는 과정에서 방해받지 않기 위해 도메인 객체를 시스템의 다른 기능으로부터 분리해야 합니다.
계층형 아키텍처 (Layered Architecture)
소프트웨어 프로그램은 사용자 입력을 처리하고, 비즈니스 로직을 수행하며, 데이터베이스에 접근하고, 네트워크를 통해 통신하고, 사용자에게 정보를 표시하는 등 다양한 작업을 수행하도록 설계되고 코드화됩니다. 각 프로그램 기능에 관련된 코드는 상당히 많을 수 있습니다.
객체 지향 프로그램에서는 UI, 데이터베이스 및 기타 지원 코드를 종종 비즈니스 객체에 직접 작성하게 됩니다. 추가 비즈니스 로직은 UI 위젯과 데이터베이스 스크립트의 동작에 포함됩니다. 이는 단기적으로는 가장 쉬운 방법이기 때문입니다.
그러나 도메인 관련 코드는 많은 다른 코드 속에 분산되어 있어 보기도 어렵고 이해하기도 어렵습니다.
관심사 분리
매우 복잡한 작업을 처리할 수 있는 프로그램을 만들려면 관심사를 분리하여 설계의 다른 부분에 집중할 수 있어야 합니다.
동시에 시스템 내의 복잡한 상호작용은 분리에도 불구하고 유지되어야 합니다. 시스템을 여러 부분으로 나누는 방법은 여러 가지가 있지만, 경험과 관례를 통해 업계는 계층형 아키텍처로 수렴하게 되었습니다.
계층의 메타포는 매우 널리 사용되기 때문에 대부분의 사람들에게 직관적으로 느껴집니다.
계층의 가치는 각 요소가 컴퓨터 프로그램의 특정 측면에 전문화된다는 점입니다. 이는 각 측면의 설계를 더 응집력 있게 만들고, 이러한 설계를 훨씬 더 쉽게 해석할 수 있게 합니다.
물론, 가장 중요한 응집력 있는 설계 측면을 분리하는 것이 중요합니다.
사용자 인터페이스 (UI) 계층: 사용자에게 정보를 보여주고 사용자의 명령을 해석하는 역할을 합니다.
애플리케이션 계층: 소프트웨어가 수행해야 하는 작업을 정의하고, 표현력 있는 도메인 객체가 문제를 해결하도록 지시합니다. 이 계층은 얇게 유지되며, 비즈니스 규칙이나 지식을 포함하지 않고, 작업을 조정하고 도메인 객체의 협력을 위임하는 역할만 합니다.
도메인 계층: 비즈니스 개념, 비즈니스 상황에 대한 정보, 비즈니스 규칙을 나타내는 역할을 합니다. 비즈니스 상황을 반영하는 상태를 제어하고 사용하지만, 저장하는 기술적 세부 사항은 인프라 계층에 위임됩니다. 이 계층은 비즈니스 소프트웨어의 핵심입니다.
인프라 계층: 상위 계층을 지원하는 일반적인 기술적 기능을 제공합니다. 예를 들어, 애플리케이션을 위한 메시지 전송, 도메인을 위한 영속성, UI를 위한 위젯 그리기 등이 있습니다. 인프라 계층은 또한 네 계층 간의 상호작용 패턴을 지원할 수 있습니다.
일부 프로젝트는 사용자 인터페이스와 애플리케이션 간에 명확한 구분을 두지 않습니다.
도메인 계층의 분리
복잡한 프로그램을 계층으로 분할하여, 각 계층 내에서 응집력 있는 설계를 개발하고, 하위 계층에만 의존하도록 합니다. 표준 아키텍처 패턴을 따라 상위 계층과의 느슨한 결합을 제공합니다.
도메인 모델과 관련된 모든 코드를 하나의 계층에 집중시키고, 사용자 인터페이스, 애플리케이션, 인프라 코드와 분리합니다.
도메인 객체는 자신을 표시하고, 저장하고, 애플리케이션 작업을 관리하는 책임에서 벗어나 도메인 모델을 표현하는 데 집중할 수 있습니다.
도메인을 인프라 및 사용자 인터페이스 계층에서 분리하면 각 계층의 설계가 훨씬 더 깔끔해집니다. 분리된 상태에서 각각은 서로 다른 속도로 발전하고 서로 다른 요구에 대응하기 때문에 유지 관리 비용이 훨씬 적게 듭니다.
또한 분리는 분산 시스템에서의 배포를 용이하게 하며, 서로 다른 계층을 서로 다른 서버나 클라이언트에 유연하게 배치하여 통신 오버헤드를 최소화하고 성능을 향상시킬 수 있게 합니다.
계층 간의 관계
지금까지 논의는 계층의 분리와 이를 통해 프로그램 각 측면의 설계를 개선하는 방법에 중점을 두었습니다. 그러나 당연히 계층은 연결되어야 합니다.
계층은 느슨하게 결합되어 있어야 하며, 설계 의존성은 한 방향으로만 존재해야 합니다. 상위 계층은 하위 계층 요소를 공개 인터페이스를 통해 호출하고, 참조를 일시적으로 보유하며, 일반적인 상호작용 수단을 사용하여 요소를 사용하거나 조작할 수 있습니다.
그러나 하위 계층의 객체가 상위 계층과 통신해야 할 때(직접적인 쿼리에 답하는 것 외에) 다른 메커니즘이 필요합니다. 이러한 상호작용을 위한 패턴에는 콜백이나 옵저버(Observer) 패턴이 포함됩니다.
UI를 애플리케이션 및 도메인 계층에 연결하는 패턴의 조상은 모델-뷰-컨트롤러(MVC)입니다. 이는 1970년대 스몰토크(Smalltalk) 세계에서 시작되었으며, 이후 많은 UI 아키텍처에 영감을 주었습니다. 상위 계층은 하위 계층의 서비스를 호출하고, 하위 계층은 상위 계층과의 통신에서 독립적이어야 합니다.
인프라 계층
인프라 계층은 보통 도메인 계층에서 동작을 시작하지 않습니다. 도메인 계층 "아래"에 있기 때문에 도메인에 대한 구체적인 지식이 없어야 합니다. 이러한 기술적 기능은 주로 서비스의 형태로 제공됩니다.
이러한 분리는 애플리케이션 계층을 단순하게 유지하고, 메시지를 언제 보낼지를 알고 있는 반면, 어떻게 보낼지는 부담하지 않게 합니다.
애플리케이션 계층과 도메인 계층은 인프라 계층이 제공하는 서비스를 호출하며, 서비스의 범위가 잘 선택되고 인터페이스가 잘 설계되면 호출자는 느슨하게 결합되고 인터페이스에 캡슐화된 복잡한 동작으로 인해 복잡해지지 않습니다.
아키텍처 프레임워크
서비스 형태로 제공되는 인프라가 있는 경우 계층의 동작과 느슨한 결합을 유지하는 방법은 직관적입니다. 그러나 일부 기술 문제는 더 침습적인 형태의 인프라를 요구합니다.
많은 인프라 필요를 통합하는 프레임워크는 다른 계층이 매우 특정한 방식으로 구현되도록 요구할 수 있습니다. 이러한 프레임워크는 복잡한 기술 문제를 해결하면서 도메인 개발자가 모델을 표현하는 데 집중할 수 있도록 도와줍니다.
대부분의 팀은 아키텍처 프레임워크의 일부 형태가 필요합니다. 프레임워크를 적용할 때는 도메인 모델을 표현하고 중요한 문제를 해결하는 구현을 목표로 해야 합니다. 이를 위해 프레임워크의 모든 기능을 사용하지 않을 수도 있습니다.
도메인 계층의 중요성
도메인 계층은 모델이 존재하는 곳입니다. 대부분의 시스템에서 계층형 아키텍처가 사용되며, 다양한 계층화 방식이 존재합니다. 그러나 도메인 주도 설계(DDD)에서는 특정 계층이 반드시 존재해야 합니다.
도메인 모델은 개념 집합입니다. "도메인 계층"은 해당 모델과 관련된 모든 설계 요소의 구현입니다. 비즈니스 로직의 설계 및 구현은 도메인 계층에 포함됩니다. 모델 기반 설계에서는 도메인 계층의 소프트웨어 구조가 모델 개념을 반영해야 합니다.
Last updated