[C#/WPF] MVVM + DDD패턴 적용하기

MVVM + DDD 패턴은 무엇일까?

WPF로 프로그램을 개발하다 보면 자연스럽게 MVVM 패턴을 사용하게 된다.
여기에 규모가 커지고 비즈니스 로직이 복잡해지면 단순 MVVM 구조만으로는 관리가 어려워진다.
이때 많이 같이 사용하는 것이 DDD(Domain-Driven Design)이다.

두 패턴은 서로 다른 문제를 해결하지만, 함께 사용하면 구조가 명확해지고 유지보수가 훨씬 쉬워진다.

---

MVVM과 DDD의 역할 차이

먼저 두 패턴의 역할부터 정리해보면 다음과 같다.(내용이 길어 접은 글로 대체)

 

MVVM 패턴이란? - UI 구조를 분리하는 패턴

MVVM(Model–View–ViewModel)은 UI(화면)와 비즈니스 로직을 분리하기 위한 아키텍처 패턴이다. 쉽게 말해 화면(View), 화면을 제어하는 중간 관리자(ViewModel), 실제 데이터와 로직(Model)을 각각 역할에 맞게 나누어 서로 직접 의존하지 않도록 만드는 구조이다.

 

MVVM패턴 구조 - 출처 : wikipedia

MVVM은 세 가지 요소로 구성된다.

1. View

View는 XAML로 작성되는 화면 영역으로, 버튼이나 텍스트 같은 UI 요소를 담당하며 사용자 입력을 받고 데이터를 표시하는 역할을 한다. 중요한 특징은 View에는 비즈니스 로직이 거의 존재하지 않으며, ViewModel에 바인딩하는 역할만 수행한다는 점이다.

2. ViewModel

ViewModel은 MVVM에서 가장 핵심적인 역할을 담당한다. View와 Model 사이에서 중간 관리자 역할을 하며, View에 표시할 데이터를 가공하고 Command를 통해 사용자 입력을 처리하며 상태를 관리한다. 특히 ViewModel은 View를 직접 참조하지 않고 바인딩을 통해 연결된다는 점이 중요하다. 쉽게 말해 ViewModel은 “화면이 쓰기 좋은 형태로 데이터를 만들어주는 계층”이라고 볼 수 있다.

3. Model

Model은 실제 데이터와 비즈니스 로직을 담당하는 영역이다. 데이터 저장, 유효성 검사, 계산 등의 역할을 수행하며, 나이 계산이나 특정 조건 판단 같은 로직이 여기에 포함된다. MVVM에서 Model은 단순한 데이터 객체일 수도 있고, DDD 관점에서는 도메인 모델로 확장될 수도 있다.

 

MVVM의 핵심 구조는 View와 ViewModel이 바인딩으로 연결되고, ViewModel이 Model을 사용하는 형태이다. 즉, View는 ViewModel과 바인딩으로 연결되어 데이터를 주고받고, ViewModel은 코드로 Model을 호출하여 실제 로직을 수행한다. 이 구조에서 가장 중요한 개념이 바로 바인딩이다. 예를 들어 TextBox의 Text를 ViewModel의 속성과 연결하거나, Button의 클릭을 Command로 연결하면, View는 직접 ViewModel을 호출하지 않아도 자동으로 데이터와 이벤트가 전달된다. 이 덕분에 코드비하인드를 최소화하고 UI와 로직을 효과적으로 분리할 수 있다.

 

DDD패턴이란? - 비즈니스 로직 구조를 분리하는 패턴

DDD(Domain–Driven Design)는 비즈니스 로직을 중심으로 시스템을 설계하기 위한 아키텍처 접근 방식이다. 쉽게 말해 화면이나 데이터베이스가 아니라, 실제 업무 개념(도메인)을 기준으로 구조를 나누고 설계하는 방법이다.

 

 

DDD는 주요 계층과 개념으로 구성된다.

1.Domain

Domain은 시스템의 핵심 비즈니스 로직이 위치하는 영역이다. 실제 업무 규칙과 상태를 표현하며, 엔티티(Entity), 값 객체(Value Object), 도메인 서비스(Domain Service) 등이 포함된다. 중요한 특징은 도메인이 UI나 인프라에 의존하지 않는다는 점이다.

2.Application

Application은 도메인 로직을 활용하여 실제 기능 흐름을 구성하는 계층이다. 사용자의 요청을 받아 도메인 객체를 조합하고 실행 순서를 제어하며, 트랜잭션이나 작업 단위를 관리한다. 비즈니스 규칙 자체는 포함하지 않고, “무엇을 할지”를 정의하는 역할을 한다.

3.Infrastructure

Infrastructure는 데이터베이스, 네트워크, 파일 등 외부 시스템과의 연결을 담당하는 계층이다. Repository 구현, API 통신, 하드웨어 제어 등이 여기에 포함된다. 도메인 계층이 직접 외부 시스템에 의존하지 않도록 중간 역할을 한다.

 

DDD의 핵심 구조는 Application이 Domain을 사용하고, Infrastructure가 Domain을 지원하는 형태이다. 즉, 도메인이 중심에 있고 나머지 계층이 이를 둘러싸는 구조이다. 이때 중요한 개념이 유비쿼터스 언어(Ubiquitous Language)로, 코드에서 사용하는 용어를 실제 업무 용어와 일치시키는 것이다.

정리하면 DDD는 시스템을 기술 중심이 아니라 비즈니스 개념 중심으로 설계하고, 핵심 로직을 Domain에 집중시켜 유지보수성과 확장성을 높이는 설계 방식이다.

 

 

왜 같이 써야 할까

MVVM만 사용할 경우 흔히 발생하는 문제가 있다.

• ViewModel이 점점 비대해짐
• 비즈니스 로직이 ViewModel에 섞임
• 테스트 어려움

예를 들어

 

// ViewModel에 비즈니스 로직이 섞인 경우
public void TrackTarget(Target t)
{
if (t.Distance > 1000 && t.Speed > 50)
{
// 추적 조건 판단 (비즈니스 로직)
}
}

 

이 상태가 계속 쌓이면 ViewModel이 “UI + 비즈니스”를 모두 담당하게 된다.

DDD를 적용하면 이 로직을 Domain으로 분리한다.

---

MVVM + DDD 구조

전체 구조는 보통 이렇게 나뉜다.

• View (XAML)
• ViewModel
• Model(DDD로 대체)
• Application
• Domain
• Infrastructure

흐름은 다음과 같다.

View → ViewModel → Application → Domain
                                           ↓                                      ↑
                                   Infrastructure                    」

 

---

각 계층 역할

View

• UI만 담당
• 로직 없음

ViewModel

• UI 상태 관리
• Command 처리
• Application 호출

public class MainViewModel
{
private readonly TrackingAppService _service;

public ICommand TrackCommand => new RelayCommand(() =>
{
_service.Track();
});
}

 

 

Application

• 유스케이스 흐름 정의
• 도메인 객체 조합

public class TrackingAppService
{
private readonly ITargetRepository _repo;

public void Track()
{
var target = _repo.Get();
target.StartTracking();
}
}

 

 

Domain

• 핵심 비즈니스 로직

public class Target
{
public double Distance { get; set; }
public double Speed { get; set; }

public bool CanTrack()
{
return Distance > 1000 && Speed > 50;
}

public void StartTracking()
{
if (!CanTrack())
throw new InvalidOperationException();
}
}

 

 

Infrastructure

• DB, 네트워크, 장비 연동

public class TargetRepository : ITargetRepository
{
public Target Get()
{
// 외부 데이터 가져오기
}
}

 

---

핵심 포인트

이 구조에서 가장 중요한 건 의존 방향이다.

• ViewModel → Application → Domain
• Infrastructure → Domain (구현 제공)

Domain은 어디에도 의존하지 않는다.

• UI 변경 → Domain 영향 없음
• DB 변경 → Domain 영향 없음

---

실무에서 체감되는 장점

1. ViewModel이 가벼워짐
   UI 로직만 남아서 구조가 깔끔해진다.
2. 테스트가 쉬워짐
   Domain은 순수 로직이라 단위 테스트 가능하다.
3. 변경에 강함
   UI나 DB가 바뀌어도 핵심 로직은 유지된다.
4. 협업이 쉬워짐
   도메인 기준으로 역할이 나뉜다.

---

주의할 점

처음부터 과하게 적용하면 오히려 복잡해진다.

• 작은 프로젝트 → MVVM만으로 충분
• 도메인이 복잡할 때 → DDD 도입

또한 Application과 Domain의 역할을 섞지 않는 것이 중요하다.

---

정리

 

MVVM은 UI 구조를 정리하는 패턴이고,
DDD는 비즈니스 로직을 정리하는 패턴이다.

둘을 함께 사용하면

• UI와 로직이 완전히 분리되고
• 구조가 명확해지며
• 유지보수가 쉬워진다.

결국 핵심은 이것이다.

ViewModel에는 UI만,
비즈니스 로직은 Domain에 두는 것.

 

Model을 하나의 덩어리로 두지 않고,
Domain / Application / Infrastructure로 역할을 나누는 것