티스토리 뷰

Book reviews

DDD Start! 책을 읽고

Voyager Woo 2020. 8. 31. 03:13
반응형

백앤드 개발자는 서비스의 비즈니스 관련 요구사항을 정리하고 코드로 풀어낸다. 작성한 서버 프로그램은 사용자의 요청을 수행한다. 요구사항은 끊임없이 변하고 서비스는 성장한다. 그에 따라서 코드의 양도 많아지고 복잡해진다. 복잡함 때문에 변화의 속도는 느려지고 개발자들은 고통받는다. 유능한 백앤드 개발자는 이 복잡함을 잘 다루는 개발자일 것이다.

복잡함은 여러 형태로 나타난다. 우선 여기저기 의존(참조, 결합)가 많은 코드들이 있을 수 있다. 흔히 말하는 결합도가 높은 코드이다. 그리고 같은 기능이 여기저기 구현되어 관리가 되지 않는 코드가 있을 수 있다. 그리고 용어의 일관성이 없어 코드를 읽기가 어려운 경우도 있다.

나도 이런 복잡함을 경험해왔고 지금도 경험 중인 백앤드 개발자이다. 도메인 주도 설계(Domain Driven Design, 이하 DDD) 방식으로 막연하게 이 문제를 해결할 수 있지 않을까 예전부터 생각해왔었다. 그래서 DDD 관련 짧은 아티클을 보면서 필요한 부분들은 조금씩 적용하곤 했다. 그리고 어떤 부분은 내 맘대로 유추하여 코딩하곤 했다. 도메인(비즈니스)의 맥락을 코드로 잘 옮기면 그게 DDD 아닌가 라고 생각했던것 같다.

그러나 어느 순간 부터 이게 맞는지 의심이 들기 시작했다. 이론적으로 나의 방법을 점검하고 끊임없이 터져나오는 의심을 해결하기 위해서 미뤄왔던 범균님의 DDD책을 읽기 시작했다. 딱 내 상황에 맞는 책이어서 그런지 너무 쏙쏙 들어왔고 금방 책을 읽을 수 있었다. 이번 북 리뷰는 내가 인상 깊거나 잘못 알고 있던 DDD에 대해서 정리해보려고 한다.

 

개념 모델과 구현 모델

순수한 비즈니스적 개념 모델을 구현하기 위해선 구현 환경의 제약사항(프로그래밍 언어의 제약, 네트워크의 제약, 성능의 제약 등)을 반영한 구현 모델이 필요하다. 이 두가지를 분리해서 생각하는 것이 중요함을 느꼈다.

그렇게 생각한 이유는 비즈니스의 개념적인 설계를 구현하는 과정에서 적절한 구현 방식을 찾고 적절하게 타협하는 것이 개발자의 능력이며 그 능력을 훈련하기 위해서는 두가지를 구분해서 생각하는 능력이 필요하다고 느꼈기 때문이다.

애그리것 설계

애그리것은 라이프사이클을 같이 하는 개념 덩어리이다. DDD 아티클이나 책을 보면서 (이 책에서도 order 애그리것) 애그리것은 여러 엔티티와 벨류가 포함된 단위라고 생각했다. 그래서 앤티티를 설계하면서 이게 적절한 애그리것일까 고민이 많았다.

그 동안의 경험을 비추어 보면 다수의 애그리거트가 한개의 엔티티 객체만 갖는 경우가 많으며 두 개 이상의 엔티티로 구성되는 애그리거트는 드물게 존재한다.

저자의 오랜 경험상 그런 복합(?) 엔티티가 드물다는 이야기를 듣고 애그리것 자체에 대해서 더 집중해서 고민할 수 있었다.

도메인 규칙과 제약사항(비즈니스 로직)은 도메인에!

객체 지향 프로그래밍을 공부하고 DDD 아티클을 몇차례 읽었지만 내 코드는 여전히 트랜잭션 스크립트였다. 엔티티는 데이터로서 존재하고 주요 비즈니스 로직이 애플리케이션 서비스에 위치했다. 트랜잭션 스크립트의 장단점을 떠나서 그게 나름의 DDD라고 생각했던 내 자신이 부끄럽다.

도메인 계층은 도메인의 핵심 규칙을 구현한다.

DDD는 도메인의 핵심 규칙을 도메인 모델과 도메인 서비스에 두는 것을 규칙으로 한다.

Application Service 의 역할

애플리케이션 서비스는 외부의 요청을 도메인 모델과 서비스에 단지 위임하는 역할을 한다. 다시 한번 정리하면 비즈니스의 규칙이 있는 곳이 아니다.

Domain Service 의 역할

도메인 모델과 애플리케이션 서비스에 대한 이해도 잘못 되었기 때문에 도메인 서비스의 역할도 잘못 이해하고 있었다. 현재의 운영 중인 코드에서는 특정 애그리것에 대해 자주 사용되는 기능을 도메인 서비스라고 칭했다. 애플리케이션 서비스에 로직이 있고, 그 로직이 자주 중복되면서 중복을 해결하다보니 이런 해괴망측한 형태로 사고가 발전하게 되었다...

도메인 서비스는 여러 애그리것에 걸친 비즈니스 규칙을 구현할 때 사용한다. 이 책에서는 쿠폰, 상품, 회원 애그리것이 필요한 가격계산 도메인 규칙을 도메인 서비스로 풀어냈다. 이 책에서는 비즈니스 규칙이 도메인 서비스 혹은 도메인 모델인지 모호할때 팁을 알려준다. 애그리것의 상태를 변경하는 것 같으면 도메인 모델일 가능성이 높고 애그리것을 이용해 계산하는 경우 도메인 서비스일 가능성이 높다고 한다.

도메인 이벤트를 발생하는 것도 도메인 규칙?

애플리케이션 서비스에 대한 몰이해의 연장선상에서 도메인 이벤트를 발생시키는 주체도 애플리케이션 서비스에 두는 짓을 했다. 그러다보니 코드의 중복이 발생하게 되고, 나는 이게 맞는 것인가 혼란스러워 했다.

"결국 도메인 계층에 도메인의 규칙이 있어야한다"는 규칙을 전제로 조각들을 정리하기 시작하자 나도 그제서야 퍼즐이 맞춰진 것 같다.

이 책을 읽은 이후에 - 전략적 패턴과 전술적 패턴

이 책을 읽은 감동을 페이스북에 공유했더니, 선배 개발자 두분께서 에릭 에반스의 원전을 읽어보길 추천해주셨다. 이 책은 DDD의 전술적 패턴에 대해서 주로 다루고 있기 때문에 전술적 패턴 이외에도 중요한 것들을 한 번 살펴보라고 하셨다. 사실 이 둘(전략패턴, 전술패턴)에 대해서 아티클과 강의를 살짝 보았지만 정확히 이해되지 않아서 에릭 에반스의 DDD 원전을 읽어보려한다. 기대가 된다.

마무리

이 책을 읽고 고개가 자연히 떨궈졌다. 나의 몰이해를 혹시 누군가에게 전하지 않았을까 싶어 매우 부끄럽다. 

이제 DDD의 전술적인 패턴을 이용해서 현재 비즈니스를 점진적으로 개선할 계획이다. DDD의 전술적 패턴이 비즈니스의 변화와 복잡도를 다루는데 어떤 실질적인 장점을 줄지 기대가 된다.

참고

이 동영상도 이 책과 결을 같이 하는 것 같아서 추천한다!

반응형
댓글
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
«   2024/03   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
글 보관함