이것저것 하느라 그동안 못 읽었던 책인 'DDD Start!' 라는 책을 드디어 읽게 되었다.
DDD START! - YES24
DDD의 핵심 개념을 배우고 구현으로 익히기!이 책은 DDD(도메인 주도 설계)를 처음 접하는 개발자를 위한 책이다. DDD를 실제 업무에 적용할 수 있도록 기본적인 이론을 설명하고 이를 구현한 코드
www.yes24.com
읽다보니 기존에 개발했던 코드들이 기억나면서 이 책을 좀 더 미리 읽었다면 좀 더 개발을 잘 할 수 있었을 것이라 생각이 들었다.
먼저, 기억나는 부분은 '가격 관련 코드는 어느 영역 있어야 하는가?' 와 같은 것이다. 상품의 가격은 쿠폰으로 인해 할인받을 수 있고 특수한 이벤트로 인해 할인이 될 수 있다. 그동안에는 이 책에서 얘기하는 applcation service 레이어에 두었다. 예를 들어 클래스명은 `CalcProductPriceService` 와 같이 말이다. 해당 클래스에선 메소드 파라미터 내에 couponId 가 존재하면 DI 받은 coupon repository 를 통해 조회하고, event Id 가 존재하면 event repository 를 통해 조회하는 식으로 optional 하게 개발하였던 것 같다. 결국 `CalcProductPriceService` 클래스는 결국 이렇게 구현했을 듯 싶다.
책을 읽고 나서는 최종 가격을 구하는 로직을 domain service 로 분리했으면 어떨까 싶었다. 최종가격을 구하는 로직엔 쿠폰 및 이벤트 타입 별로 할인 로직이 각각 다르게 들어가 있을 것이니 이러한 로직들을 domain service 로 분리했다면 조금 더 유지보수하기 쉬운 코드가 됐을 것 같다. 왜냐하면 추후 쿠폰 및 이벤트 도메인에 할인 타입이 추가된다면 해당 `CalcProductPriceService` 클래스의 `process(...)` 메소드의 로직을 확인한 뒤에 수정했어야 했겠지만 아래와 같은 domain service 클래스가 추가된다면 해당 클래스만 보고 로직을 수정하면 되기 때문이다.
그리고 한 가지 더 얘기할 점이 있다. 기존에 port and adapter 에 대해 공부하고 적용해보면서 비즈니스 로직에 저수준 구현체에 대한 코드 및 어노테이션을 넣기 싫었던 적이 있었다. 나중에 구현체가 바뀔 것을 고려해서 말이다. 또한, 단위 테스트 시 저수준 구현체가 들어있어 테스트하기 어려워지는 것도 있다고 생각했기에 꺼려했었다. spring boot 와 RDB 를 쓰는 회사에서는 보통 jpa 를 사용할 것인데 이 때 저수준 구현체가 되는 jpa 를 분리해야 할 것인가에 대해 엄청 고민을 많이 했었다. 만약 jpa 에 의존하지 않겠다고 개발을 해버리면 너무 많은 클래스가 생성이 되고, jpa 장점이라고 할 수 있는 부분들을 이용하지 않고 개발을 하게 되는 것이었다. 우선 해당 프로젝트에서 특정 데이터들이 mysql 로 관리되고 있었는데 추후 nosql 로 이관될 수 있다는 얘기가 있어 고심하다 jpa 를 의존하지 않고 개발하는 것으로 했다. 이게 최대의 실수였었다. 개발 속도가 너무 느려졌다. 책에서 말하는 것도 이러한 부분들은 트레이드 오프라고 하는 것 같다. 정말 그래도 nosql 로 이관되는 경우를 생각했었기 때문에 그 시기가 되면 빛을 발할 것인데 그전까지는 너무 손실이 큰 것 같아서 반성한다. 너무 먼 미래를 본 것이 아닐까 하는 생각이 들고 이것이 바로 내가 전부터 하면 안 된다는 오버 엔지니어링에 한 부분이라고 생각이 든다. 반성하고 더 발전하자..
마지막으로 바운디드컨텍스트와 에그리거트 관련 내용이 나오는데 예와 함께 코드까지 같이 보여주기에 괜찮았던 것 같다. 결국 핵심은 비즈니스 로직과 도메인 로직 분리 및 의존성 관리인 듯하다. 아직 내가 봤을 때 우와! 를 외치게 하는 코드는 보지 못했기에 알쏭달쏭 한 부분이 있는데 언젠간 내 가려운 부분을 긁어줄 수 있는 코드를 볼 수 있으면 좋겠다. 우선 그전에 누군가가 봤을 때 내 코드를 보고 그런 감탄사가 나오기를 바라며 개발을 잘해야겠다.
어쨌든 좋은 책이었던 것 같다.