도메인 주도 설계의 사실과 오해 특강

소프트웨어의 본질 #

소프트웨어의 본질은 사용자를 위해, 문제를 해결하는 것이다.

사용자가 프로그램을 사용하는 주제 영역

DDD는 (1)객체 지향, (2)애자일이라는 개념에 의해 나타났다. 즉, 두 개념을 이해해야 DDD를 정확히 이해할 수 있다.

객체 관련 커뮤니티에서 내가 ‘도메인 주도 설계’라고 칭하는 하나의 철학이 나타났다. … 이 책은 객체 모델링을 어떻게 실제 소프트웨어 프로젝트에 적용할 것인지에 대해 몰랐던 부분을 채워주고 시각 또 한 향상시킬 것이다.
도메인 주도 설계 ‘서문’ 중에서 -

위에서 언급한 것 처럼 DDD는 객체 지향이라는 것을 어떻게 큰 프로젝트에 적용할 수 있을지에 대한 방법론이었다.

객체 지향의 이론은 1990년대 중반에 정리가 됐고 2000년대 초반에 활발하게 적용됐다. 1990년대 ~ 2000년대에 나타났는데 우리나라에는 뒤늦게 전파됐다.

GUI 가 흥행하면서 ‘객체’ 라는 개념이 활발하게 사용됐다. ‘디자인 패턴 by GOF (1994)’ 책의 디자인 패턴도 대부분 UI 설계에서 유래됐다.

2000년대에는 분산 객체 기술이 유행했다. (망했다.) 최근에 분산 서버(MSA)가 유행하는 것 처럼 그때 당시엔 분산 객체가 유행했었다.

분산 객체가 유행하면서 EJB(침투적 기술)이 나왔다. 침투적이라고 표현하는 이유는 객체를 만들 때 도메인 지식만 생각해도 되는 것이 아니라 EJB 스펙(기술)까지 생각해야 하기 때문이다.

어떤 특정한 구현 기술보다 객체 지향 설계가 더 중요하다.
로드 존슨 -

POJO 기반의 비침투적인 경량 컨테이너, 즉 스프링이 출시됐다.

이 시점에 도메인 주도 설계 책이 나왔다. 이때는 기술에 관심이 쏠려 있던 때인데, 기술이 중요한게 아니고 우리의 근본(소프트웨어의 본질)에 대해 생각해봐야 한다는 움직임에 의해서 나왔다.

근본적으로 중요한 것(= 도메인)에 집중하자는 것이다. 도메인에 집중하고 보니, (커뮤니케이션, 유지보수 등을 위해)도메인과 코드 표현의 차이가 최소화되는 것이 좋았다. 즉, 객체 지향 설계/개발이 기반이 되어야 했다.

레이어 아키텍쳐, 엔티티, VO 등 모든 것은 도메인 로직을 잘 작성하기 위한 방법들이다. 이것들이 ‘주’가되면 안된다. ‘도메인’이 주가 되어야 한다.

어떤 도메인 로직을 작성하기 위한 방법으로 A라는 기술을 쓸 수 있다. 만약 A라는 기술의 사용이 불편하다면 다른 기술을 사용하는 것이 맞다.

현실의 문제, 문제를 해결하기 위한 코드를 작성하면 그것이 바로 ‘도메인 로직’이다.

즉, 도메인 로직이란 사용자의 문제를 해결하기 위한 코드다. 도메인 로직과 다른 로직이 섞여 있다면 대응(커뮤니케이션, 유지보수 등)이 효과적으로 이뤄지지 않는다.

도메인 로직과 별개의 로직(트랜잭션 관리, 로깅 등)을 격리한다.

…