이 문장은 「Tech Fun Advent Calendar 2017 」13일째의 기사입니다.

질서가 없는 프로젝트를 리팩토링해 나가는 가운데, DDD를 단계적으로 도입해 가는 어프로치나 감상에 대해입니다.

한 프로젝트에 참여한 초기 상태

Java8에서 Spring Boot인 프로젝트입니다만, 아래와 같은 코드였습니다.

코피페코드가 많다.

단위 테스트 없음.

Controller에서 Service로 "Model"을 전달하고 있으며, 어떤 View를 표시할지는 Service가 알고 있다.

Service 에 MyBatis 의 자동 생성된 mapper 를 사용해 DB 액세스가 모두 쓰여져 있다.

Service가, 화면·기능에 대응한, 이른바 트랜잭션 스크립트가 되고 있다.

Controller가 기능하고 있지 않다는 것은 제쳐두고, Service가 트랜잭션 스크립트가 되어 버리고 있다고 하는 것은, 비교적 있는 것이 아닐까 생각합니다.

무엇이 문제인가?

변경에 약하다. 이것에 다해. 비즈니스 규칙이 변경되면 횡단적으로 변경이 발생하고 변경 누출이 있으면 당연히 버그가 됩니다. 테스트도 어렵습니다.

첫 번째 접근

DDD 이전의 이야기입니다만, 팀 멤버와 토론해, 문제 인식을 가지는 것이 중요하다고 생각하고 있습니다. 레이어를 적절하게 분할하고 테스트를 작성합니다.

레이어 분리

구성요소
책임


컨트롤러
요청, 응답 처리.

서비스
비즈니스 로직을 기술한다. 웹의 관심사를 여기에 가져오는 것은 안 된다. 영속화도 여기서 해서는 안된다.

리포지토리
영속화를 실시한다. 쿼리 던지는 것도 여기서 추상화하고, 도메인 계층에서는 컬렉션으로서 취급한다. 인터페이스와 구현은 나눕니다.


여기에서 3층+도메인 모델로 가져갑니다.

테스트 작성

스케줄과의 겸용도 있어, 실제로는 타협해 크리티컬한 것을 우선해, 필요 최저한의 기능에 짜서 단체 테스트를 썼습니다.

단계적으로 DDD를 도입한다

변경에 약한 코드란 어떤 코드일까요?

데이터 클래스와 기능 클래스를 구분하는 프로시저형 설계에서는 중복된 비즈니스 로직이 어디에나 쓰여집니다. 그 결과 어디를 변경해야할지 모르겠습니다.

반대로 변경에 강한 코드란 어떤 코드일까요?

데이터와 비즈니스 로직이 정리된 개체군(도메인 모델)으로 구성됩니다. 관심사 단위로 분리하여 어디를 변경해야 하는지 바로 알 수 있습니다.


인용: 현장에서 도움이 되는 시스템 설계의 원칙 ~변경을 편하고 안전하게 하는 오브젝트 지향의 실천 기법 3층+도메인 모델로 관심사를 알기 쉽게 분리한다

View, Service에서 도메인 모델을 추출해 간다

기본적으로는 「업무에 사용하고 있는 용어를 클래스명으로 한다」가 좋다고 생각합니다. 좋은 클래스명이나 메소드명이 없는지 항상 생각하는 것이 중요하고, 사고 정지하면 레거시 코드화가 진행됩니다.
도메인 모델 구동 설계는 부분에 주목하고 개별 부품을 조합하여 단계적으로 전체를 만드는 접근이 가능하기 때문에 DDD는 신속하게도 도입 가능하다고 실감하고 있습니다.

참고서적

DDD

최근에는 현장에서 도움이 되는 시스템 설계의 원칙 ~변경을 편하고 안전하게 하는 오브젝트 지향의 실천 기법 근처에서 입문하는 것이 좋습니다.

허리를 잡고 읽을 필요는 있지만 아래도 필독입니다.
· 에릭 에반스의 도메인 중심 설계
· 실습 도메인 구동 설계