소프트웨어 개발의 복잡성이 계속 증가함에 따라 개발팀이 직면하는 과제도 점점 더 중요해지고 있습니다. 시간이 촉박하든 요구 사항이 바뀌든, 개발자는 프로젝트 개발 프로세스를 보다 효율적으로 만들 수 있는 솔루션을 찾아야 합니다. 현재, 도메인 주도 설계(DDD)가 인기 있는 전략이 되었습니다.
"핵심 분야에 집중하는 것은 선택이 아니라 필수입니다."
도메인 주도 설계의 가장 중요한 개념은 소프트웨어 모델을 비즈니스 도메인과 효과적으로 연결하는 것입니다. 개발자는 해당 분야 전문가와의 심도 있는 대화를 통해 비즈니스 로직을 이해하고, 사용자 요구 사항을 충족할 뿐만 아니라 지속적으로 유지 관리가 가능한 소프트웨어 시스템을 구축할 수 있습니다. 이러한 접근 방식의 핵심은 모든 문제를 한꺼번에 해결하려고 하지 않고 핵심 영역에 집중하는 것입니다.
도메인 기반 설계를 통해 대규모 시스템을 여러 개의 "경계된 컨텍스트"로 나눌 수 있으며, 각각은 자체적인 독립적인 모델을 갖습니다. 이러한 구분은 개발팀이 특정 기능 분야에 집중하는 데 도움이 되고 부서 간 간섭을 줄여줍니다. 동시에, 이를 통해 비즈니스 전문가와 개발자 간의 창의적인 협업이 촉진되고, 컨셉트 모델을 반복적으로 수정할 수 있습니다.
"모델의 디자인은 비즈니스 요구 사항에 부합해야 합니다. 이것이 시스템을 쉽게 유지 관리하는 데 중요한 요소입니다."
도메인 기반 디자인을 사용하는 또 다른 이점은 통합된 언어의 중요성을 강조한다는 것입니다. 소위 유비쿼터스 언어란 비즈니스 전문가, 사용자, 개발자가 사용하는 언어로, 모든 참여자가 비즈니스 요구 사항을 명확하게 이해하는 데 도움이 될 수 있습니다. 모든 사람이 동일한 맥락에서 의사소통하므로 의사소통 오류를 효과적으로 줄이고 프로젝트 진행을 촉진할 수 있습니다.
그러나 비판론자들은 DDD를 구현하려면 모델 순수성과 유용성 측면에서 많은 격리 및 캡슐화 작업이 필요하다고 지적합니다. 즉, 개발자는 모델 경계 내에서 일관성을 지속적으로 유지해야 하며 향후 수정 사항을 추가적인 부담으로 간주해야 합니다. 특히 규모가 작거나 복잡하지 않은 프로젝트의 경우 이러한 접근 방식은 불필요한 오버헤드를 초래할 수 있습니다. 따라서 Microsoft에서는 모델이 공유된 비즈니스 이해를 명확하게 제공하는 경우에만 복잡한 도메인에서 DDD를 도입하는 것을 권장합니다.
DDD는 여러 모델이 존재하며, 그 중 가장 일반적인 모델에는 엔터티와 값 개체가 포함된다는 것을 인식합니다. 개체(entity)는 그 정체성에 의해 정의되는 객체인 반면, 값 객체(value object)는 그 속성에 의해 정의되며 개념적 정체성을 갖지 않습니다. 예를 들어, 대부분의 항공사는 항공기의 각 좌석에 고유 번호를 부여하는데, 이를 통해 좌석을 식별합니다. 반면, 사람들이 명함을 교환할 때는 카드에 적힌 정보에 더 많은 관심을 기울이고, 각 카드의 독특성에는 특별한 주의를 기울이지 않습니다.
"다양한 유형의 모델을 이해하는 것은 DDD를 마스터하는 데 있어 초석입니다."
DDD에서는 객체를 만드는 프로세스가 객체 자체와 분리되는 경우가 많습니다. 예를 들어, Repository는 데이터베이스와 같은 데이터 저장소에서 도메인 객체를 검색하는 메서드를 갖춘 객체입니다. 팩토리는 도메인 객체를 직접 생성하는 데 사용됩니다. 또한 프로그램 기능 중 일부가 개념적으로 어떤 객체에도 속하지 않는 경우 일반적으로 서비스를 통해 표현될 수 있습니다.
DDD에서는 이벤트를 여러 유형으로 나눌 수 있는데, 그 중 가장 중요한 것은 '도메인 이벤트'와 '통합 이벤트'입니다. 도메인 이벤트는 특정 비즈니스 도메인 내에서 중요한 발생을 알리는 신호이고, 통합 이벤트는 서로 다른 경계 컨텍스트 간의 변경 사항을 전달하는 데 사용됩니다. 둘 다 시스템 데이터 일관성과 비즈니스 로직 무결성을 보장하는 데 중요한 역할을 합니다.
컨텍스트 매핑은 다양한 도메인이나 하위 도메인의 경계를 식별하고 정의하는 데 중요합니다. 이러한 맥락들이 어떻게 상호 작용하고 관련되어 있는지 시각화하는 것은 명확한 경계를 유지하고 결합을 줄이는 데 도움이 됩니다.
도메인 기반 설계는 반드시 객체 지향 방법과 함께 사용되는 것은 아니지만, 실제로는 이러한 기술의 장점을 보완합니다. 기존 아키텍처와 달리 DDD는 구체적인 기술 프레임워크보다는 비즈니스 행동에 초점을 맞춥니다.
요약이벤트 스토밍, 이벤트 소싱 또는 경계 컨텍스트를 마이크로서비스에 매핑하는 방법을 통해 DDD는 개발자가 비즈니스 요구 사항을 이해하고 구현하는 데 도움이 되는 일련의 도구와 방법을 제공합니다. 궁극적으로 핵심 영역에 집중하면 프로젝트 성공 가능성이 높아질 뿐만 아니라 향후 유지 관리 비용도 효과적으로 절감됩니다. 이러한 맥락에서, 귀사의 핵심 분야에 초점을 맞추는 것이 귀사의 개발 프로젝트에 어떤 종류의 변화를 가져올 수 있는지에 대해서도 생각해 보셨습니까?