DDD 적용 전후

MSA에서 그 첫단추는 바로 서비스를 식별하고 검증하는 것이다. MSA 구현에 관련된 기술적인 자료는 많지만 논리적으로 또는 뭔가 근거와 협의를 통해 서비스를 식별하는 것에 대한 내용은 그리 많지 않다. 식별/검증 방법이 여럿 있겠으나 그중에서도 DDD의 개념을 많이 가져다 이야기한다. 마치 DDD를 모르면 MSA를 할 수 없는듯한 느낌을 받을때도 있다.

DDD에 대해서도 많은 자료가 있지만, 그중에서도 전략설계, 전략설계중에서도 Sub Domain, Bounded Context, Context Map 등 개념을 통해 정리해가다보면 그게 바로 MSA에서 원하는 Microservice와 많이 닮게 된다는 이야기인듯하다.

 

하지만 처음 접하는 사람의 입장에서는 어렵다. 위에서 언뜻 이야기한 몇몇 용어만으로도 쉽지 않다. DDD관련 책, 원서든 번역본이든 역시 쉽지 않다. 사이트 설명도 대부분 그렇게 어려운 책들을 저마다 정리해서 더 혼란스럽다.

DDD의 전체 개념과 흐름을 모르는 상태에서 일부 개념을 따다가 MSA에 적용하려니 이도 저도 아닌듯, 맞나 싶다.
DDD를 제대로 이해한다면 위의 혼란스런 느낌이 많이 정리될 것이다. kooangelo.tistory.com/151 에서 책 3권을 소개하고 있는데 소개하는 역순으로 읽는게 처음 접하기에 좋다.

MSA에서 서비스를 나누기 위한 Event Storming 등을 위해 DDD를 이용하면 되는것으로 이야기하는 사람들도 있다. 알록달록 포스트잇 몇개 붙인다고 당연히 될리 없다. DDD는 뭐고, 왜 Event Storming 이야기를 하는것이며, 그게 Microservice와 무슨 관련이 있는것인지, 어떻게 써먹으려는 것인지를 알아야 (흉내가 아닌) 자기것이 될 것 이다.

위의 두꺼운 책들을 정리하는데는 시간이 좀 걸리니, 일단 DDD가 뭔지 보자. 처음에는 뜬 구름 잡는듯 했는데 보면 볼수록 MSA이전에 소프트웨어 설계/개발의 기초체력에 해당되는 느낌이다.

 

도메인 주도 설계, 혹은 DDD라고 불리는 소프트웨어 개발의 접근법은 우리가 높은 품질의 소프트웨어 모델을 설계할 수 있도록 해준다. DDD를 정확하게 구현했을 때, DDD는 우리가 만든 설계가 소프트웨어 동작에 정확히 어떻게 반영되는지를 볼 수 있도록 해준다.

 - Implementing Domain-Driven Design 도메인 주도 설계 구현, 반 버논, 1장 DDD를 시작하며 p.51

위의 내용을 보니 말이 맞는긴한데, 와 닿지 않는다. 그래서 아래와 같이 단적으로 DDD적용 전/후를 보자. (전체라고 이야기할 순 없지만 느낌은 온다.)

 

아래의 샘플 코드 및 내용은

Implementing Domain-Driven Design 도메인 주도 설계 구현, 반 버논, 1장 DDD를 시작하며 p.68 ~ p.77 중에서 발췌, 정리한 것이다.

 

DDD 적용 전

public void saveCustomer(String id, String name, String address, ... ) {
  Customer customer = customerDao.readCustomer(id);

  if(customer == null) {
    customer = new Customer();
    customer.setCustomerId(id);
  }

  customer.setName(name);
  customer.setAddress(address);
  customer.setHomePhone (...);
  customer.setEmail (...);
  ...

  customer.saveCustomer(customer);
}

무엇을 하는 코드인가. 꽤 다양한 용도의 코드이다. 신규든 기존 고객이든 Customer를 저장한다. 이름이 바뀌든, 이사를 가서 주소가 바뀌든, 전화를 새로 놓든/끊든, 직장이 바뀌든, 이메일 주소가 변경되든 Customer를 저장한다. '우와, 굉장한 방법인데? ... '

어떤 비즈니스 상황에서 이 메소드가 사용됐는지 모른다. 왜 이 메소드가 애당초 만들어졌나? 이 메소드가 만들어지고 수정된 지 몇주나 몇 달 뒤면 아마도 이 기억은 사라질것이다.

saveCusomer(...) 인터페이스를 통해 알 수 있는 의도가 거의 없다. saveCusomer(...) 의 구현 그 자체가 숨겨진 복잡도를 높인다. 도메인 객체 Customer는 사실 전혀 객체가 아니다. 단지 데이터 홀더일 뿐이다.

 

 

DDD 적용 후

도메인 전문가와 개발자가 충분히 상의하고 Ubiquitous Language(UL)를 함께 정의한다.
그러한 지식을 바탕으로 saveCustomer(...)를 다시 설계한다면?
도메인 전문가가 포함된 개발팀이 반드시 지원해야하는 발생 가능한 비즈니스 목표를 Customer에 반영한다면?

 

public interface Customer {
  public void changeCustomerName(String firstName, String lastName);
  public void relocateTo(PostalAddress changedPostalAddress);
  public void changeHomeTelephone(Telephone telephone);
  public void disconnectHomeTelephone();
  ...
}

 

메소드 명만 봐도 어떤일을 하는지 도메인 전문가도 알 수 있다.
다양한 비즈니스 목표를 명시적으로 반영한다.
각 서비스 메소드는 하나의 Usecase 또는 User Storyg를 처리한다.
위의 여러가지 메소드중 changeCustomerName 를 예로 보면 아래와 같다.

 

public void changeCustomerName(String customerId, String firstName, String lastName) {
  Customer customer = customerRepository.customerOfId(customerId);

  if(customer == null)
    throw new IllegalStateException("Customer does not exists");

  customer.changeCustomerName(firstName, lastName);
}

위에서도 등장하는 UL, 이 역시 이해하기 어려운 개념이다.
그래서 다음번엔 UL도 적용전후를 단적으로 한번 보겠다.