[도메인주도설계 철저입문] 어려운 DDD 포기하지 않을 수 있는 시작점

객체지향 외에 도메인주도설계 기법이 있음을 알게 되었고, 먼저 에릭에반스의 책을 읽어보았다. 아니나 다를까 여느 설계 책들 마냥 쉽지 않았고, 아무래도 경험이 많지 않아서 그런지 나에겐 더 어려웠다. 한글로 번역된 책을 읽는데 한 문장을 몇 번씩 읽어도 머리속에서 이해가 되지 않았다.

그래서 찾은 대안이 이 책이었다.

이 책은 각각의 DDD 개발 사례를 토대로 페이지가 진행된다.

DDD의 구성은 크게 값객체, 엔티티, 서비스, 리포지토리, 애그리게이트, 명세 등이 있다.
문제는, 기존의 객체지향 개념만을 가지고 '비슷한 거구나~' 하고 착각된 개념을 가지면 나중에 안맞거나 그냥 객체지향이랑 차이가 없는 것이 되곤 한다.

 

특히나 굳이 '도메인' 주도 설계인 이유가 있는데, 그 모호한 개념을 잡기가 너무 어려웠다. 물론, 결국 구성요소의 '역할'마다 붙이는 이름은 다르지만, 객체로 구성한다는 점에서 객체지향이기도 한데, 객체지향처럼 하자니 도메인쪽에서 잘 안맞고, 도메인대로 하자니 객체가 너무 복잡해지곤 했다.

내가 이해한 바를 요약해 보자면, DDD는 도메인 개념과 최대한 같은 형태로 동작하는 구조를 보이게 만드는 설계기법이다. 따라서, 도메인 내용 상에 추가 혹은 변경이 있더라도 그 변경으로인해 다른 내용을 너무 많이 수정할 필요가 없게 하는 것이 핵심이다.

객체의 행동과 정의가 기준이 아니라, 객체가 갖는 '의미'가 기준이라는 느낌을 받았다. 이 '의미'라는 것이 하나의 객체에 대해 상대적인 의미 여러개를 내포할 수 있어서 더 많이 헷갈렸었고 지금도 헷갈리곤 한다.

 

DDD를 설명할 때는 항상 예시 코드가 같이 나오며, C#으로 구현되었다. 각 코드가 어떤 의미를 위해 작성되었는지, 그렇게 하면 얻는 이점은 무엇인지도 같이 나와있다.

단점을 하나 뽑자면, 각 설명의 전체 코드에서 사실 설명하는 내용에 해당되는 부분은 일부인 경우가 꽤 있다. 이런 부분은 아무래도 초보자가 보기엔 헷갈리거나 다른 코드를 잘못 이해하는 경우가 생기지 않을까 싶다. 아무래도 설명하고자 하는 내용 자체가 굉장히 모호하기 때문에 이 부분이 특히나 읽는데 어려울 수 있겠다 싶었다.

 

개인적인 평을 하자면, 필요는 하지만 이해하는 난이도가 너무 높은 책만 있는 상황에서 나름 단비같은 가교역할에 충실한 책이었다.