도메인 주도 설계 첫걸음-Vlad Kononov
README#
Giftogether 서비스를 개발하면서 새 기능을 추가하는데 기존 기능들에 영향을 가지 않게 설계하기 위해 도메인 로직을 먼저 작성하기 위해 DDD를 찾아봤다. 여러 블로그글이 NestJS를 위한 도메인 주도 개발 방법론이 나와있지만 그걸로는 부족해 책을 한 권 구매했다. 이 책을 읽으면서 비즈니스 로직을 도메인 영역으로 옮겨 실제 구현코드와의 링구아 프랑카를 작성하는 능력, 소통하는 능력을 기르길 희망한다.
2024-12-12 목차, 서문, 맺음말, 부록 A#
서문과 목차, 그리고 맺음말과 부록의 마켓노퍼스 사례 연구를 먼저 읽어봤다. 아직 용어가 대부분 정립이 되어있지 않아 애그리게이트, 유비쿼터스 언어, 도메인 모델과 하위 도메인 모델이 쏟아지지만 저자는 내가 마치 이 책을 다 읽어본 것처럼 능수능란하게 이야기했다(당연하겠지 맺음말이니까).
오히려 단어 자체의 정의를 먼저 들여다보기 전에 어떤 맥락에서 사용되는지 넘겨짚으니까 많은 생각을 할 수 있었다. '애그리게이트' 라는 단어는 어떤 도메인 모델에 기능을 붙일때 쓰이고 트랜잭션 경계와 긴밀하게 얽혀있다는 것을 알았다. '하위 도메인 모델' 은 그 중요도와 변동성 등에 따라서 핵심 하위 도메인, 일반 하위 도메인, 지원 하위 도메인으로 나뉘며, 그다지 중요하지 않은 하위 도메인의 경우엔 단순히 '액티브 레코드' 스크립트만 사용해도 좋다고 한다 👀? '유비쿼터스 언어' 야 말로 회사가 돌아가는 업무 언어를 식별하는 수단이고, 유비쿼터스 언어가 잘 정의되어 있으면 의사소통에 굉장한 도움이 되기 때문에 선택사항이 아니라고 두 번 강조했다.
Scraps#
- Active Record 액티브 레코드는 DB 테이블 또는 View의 행을 감싸고 DB 접근을 캡슐화하고 해당 DB에 도메인 로직을 추가하는 객체이다 - p.72
- ORM은 액티브 레코드를 추상화한 것이라고 봐야지.
- 액티브 레코드 스크립트는 지원 하위 도메인, 일반 하위 도메인에서 사용되며, 복잡하지 않은 비즈니스 로직에서 자주 활용된다.