Yunseok's Dev Blog

배운 것을 적는 블로그입니다.

개발자 한 달에 책 한 권 읽기 모임 회고 - 도메인 주도 설계 구현 4장 까지

도메인 주도 설계 구현

책이 워낙 어려워서 혼자 이해하기 어려운 부분이 많았다. 책에서 요구하는 수준이 DDD를 시도해 본 적이 있고, 도메인 주도 설계 책을 읽은 것을 가정하여 쓰였다 보니 더욱 어려웠다. 어떻게든 해서 읽었는데, 개념들이 장 정리가 안됐다. 그래서 같이 개념 정리를 했다.

가장 중요하게 얘기했던 도메인과, 서브도메인, 핵심도메인, 바운디드 컨텍스트 용어에 대해 정리했다. 도메인은 사용자가 소프트웨어를 사용하는 분야의 전반적인 지식인데 이 도메인이 복잡하다 보니 우리는 작은 서브도메인들로 나눈다. 이 서브도메인 중에서 비즈니스의 가치를 가져오고 다른 곳들과 차별화를 가져오는 것이 핵심도메인이다. 이 복잡한 도메인을 이해하기 위해 우리는 모델을 만든다. 그것이 도메인 모델이고 소프트웨어로 구현할 수 있다. 해당 도메인 모델이 존재하는 명시적인 경계를 바운디드 컨텍스트라고 한다. 유비쿼터스 언어가 특정한 컨텍스트 안에서만 의미를 갖는데 이 컨텍스트의 의미의 경계를 구분 짓는 것이 바운디드 컨텍스트다.

헥사고날의 포트와 어댑터의 구분에 대해서도 얘기했는데, 육각형 그림에서 한 면이 포트였다. 그런 것이 중요한 건 아니고 어쨌든 Input과 Output이 둘 다 의존성의 방향이 안쪽 도메인 레이어로 향하는 것이 핵심이다.

간단하게 DDD 전략적 설계를 해보았는데 도메인 전문가가 없어서 힘들었다. 학생을 관리하려는 학원을 예로 들어서 했는데 대화를 하면서 여러 가지 서브도메인들을 뽑아냈다. 학생 목록, 성적 관리, 제명, 출석 관리, 선생님, 보안 시스템, 강의, 시간표, 자습 공간, 보안 시스템 등 여러 가지 서브도메인들을 뽑아냈는데 여기서 어떤 것이 핵심도메인이 될 수 있는지에 대해서 얘기했다. 보안 시스템도 서브도메인이지만 외부 시스템을 이용할 수 있으므로 범용 서브도메인이 될 수 있다. 어떤 것을 핵심도메인으로 정하는지에 따라 어떻게 비즈니스를 할지가 정해질 수 있다.

조직에 도입하고자 할 때 DDD의 전략, 전술 중 어떤 걸 먼저 도입할 것인지에 대해서도 얘기했는데, 전술적 설계를 해보지 않은 상태에서 전략적 설계를 하려다 보면 어려울 수 있다. 마찬가지로 전략적 설계 없이 전술적 설계만 하다 보면 빈약한 도메인 모델이 만들어질 수 있다. 결론은 전부 이해하고 해야 한다.

회사에 도메인 전문가가 없을 경우에는 어떻게 해야 하는지 같이 얘기했는데 오늘 오신 분들이 다니는 회사에는 다 도메인 전문가가 있어서 놀랬다. 도메인 전문가가 없을 경우에는 비즈니스가 모호해져 프로젝트의 성공 가능성이 굉장히 낮아지는데, 어떻게 해서든 도메인 전문가를 데려오든지 아니면 내가 혹은 팀이 도메인 전문가가 되어야 한다.

유비쿼터스 언어를 어떻게 관리하면 좋을지에 대해서도 얘기했는데, 언어 사전을 만들 수도 있지만 가장 중요한 것은 유비쿼터스 언어가 코드로 표현이 되는 것이다. 대화를 할 때, 코드를 구현할 때, 사용자가 사용할 때 모두 같은 언어를 사용하는 것이 중요하다.

좋았던 점

  • 책에서 나온 개념들을 정리해서 좋았다.

아쉬웠던 점

  • 안 온 사라들이 많았다.

Sources