DDD

https://www.amazon.com/Domain-Driven-Design-Golang-maintainable-business/dp/1804613452

1. The world before DDD

2003년 DDD의 등장 이전에, 개발자들은 software와 system을 problem space로 표현하는 방식에 대해서 생각해왔다. 여기서 problem space가 바로 domain이 되고, domain에 맞게 software system을 디자인하는 것이 더 쉽게 코드를 변경할 수 있다는 것을 알아냈다. 또한, 개발자가 아닌 다른 사람들도 domain을 통해 설계에 참여하고 대화할 수 있다는 것이 큰 장점이 되었다.

문제는 점점 복합해지는 software 시스템에 domain을 도입하기 어려웠는데, 이를 위해 Eric Evans가 Domain-Driven Design: Tacking Complexity in the Heart of Software, Addison-Wesley Professional라는 책을 2003년에 발가하였다.

2. DDD의 3가지 주요한 컨셉

Evans는 DDD의 3가지 주요한 cencept들에 대해 소개했다. ubiquitous language, strategic design, tactical design이다.

1. Ubiquitous language: 우리의 domain을 설명할 때 사용하는 공통 언어로, 개발자와 비개발자의 대화에 있어 모호함을 줄여준다. domain이 발달함에 따라 ubiquitous language도 발달한다. 다만, ubiquitous language는 business language가 아니기 때문에 domain expert에 의해 강요되어서는 안된다.

2. Strategic design: business domain을 맵핑하고 bounded context를 만드는 단계이다. 이 설계 단계에서 실제 문제 공간을 추상적인 domain model로 맵핑하여, 아키텍쳐링을 한다. 다이어그램을 그리고 주요 entity들을 이어붙여 하나의 그래프를 만드는 것 또한, strategic design으로 볼 수 있다.

3. Tactical design: 실제 구체화 단계로 우리의 system이 어떻게 생겼을 지 만드는 단계이다. 이 부분에서 entities, aggregates, value objects개념이 등장하며, 이러한 패턴들을 사용하여 우리의 software boundaries를 정의하는데 도움을 줄 수 있다.

3. 언제 DDD를 사용해야할까?

그렇다고 무작정 DDD를 사용할 필요는 없다. DDD는 매우 크고, 복잡한 시스템에 도입하는 것이 좋은데, 간단한 CRUD 시스템에 DDD를 도입하는 것은 매우 많은 노력과 시간을 들이는 일이며, 효율이 좋지 않다. 재밌는 것은 실제로 소프트웨어 개발자들이 만드는 대부분의 코드는 CRUD application이며, 대부분 DDD를 도입할 필요가 없다. 오히려 DDD와 design pattern을 배웠다고 작은 spring application에 덕지덕지 패턴만 적용하면 좋은 코드를 만들기 어렵다. 역설적으로 유지보수가 더 어려워지는 경우가 더 많다. 그런 개발자들을 양성하는 캠프가 늘어나는 추세에 진또배기 개발자들을 찾기란 여간 어려운 일이 아니다.

Big Red Book에서는 DDD 스코어카드를 제공해주는데, 7점 이상을 받으면 DDD를 적용하는 것이 좋다.

1. application이 database에서 CRUD만 하고있는 simple한 구조라면 0점이다. 단, input과 output에 복잡한 business logic이 필요할 때가 있다. 단순 validating이 아닌 복잡한 로직이 이 과정에서 필요하다면 여기에 해당되지 않는다.
2. application의 business flow(user story)가 30개 보다 작다면 1점이다. business flow는 'A가 필요하다면 B를 할 수 있다.'와 같은 흐름을 말한다.
3. application의 business flow(user story)가 40개 보다 많다면 2점이다. 점점 시스템이 복잡해지고 있는 구조로 가고 있다는 전조이다.
4. application이 복잡해질 가능이 있는가? 그렇다면 3점이다. 처음에는 simple한 구조였지만, 시간이 지날수록 해결 중인 문제가 많아지고 있다면 complexity가 높아지고 있는 것이다.
5. application을 오랫동안 사용할 수 있는데, 앞으로 들어올 변화가 쉽지 않다면 4점이다. 가령, 여행자 예약 홈페이지에서 내년 달력을 추가하는 것은 어렵지 않다. 그런데 암호화폐 거래소의 새로운 프로토콜을 도입하는 것은 어려운 일이다.
6. 해당 domain에 대해서 잘 모를뿐더러 다른 사람들도 이전에 시도해본 적이 없는 경우는 5점이다. domain을 모델링하고 정의하는 것은 DDD의 핵심이기 때문이다.

7점 이상은 DDD를 적용하고, 미만이면 그대로 시스템을 개발하는 것이 좋다. 왜냐하면 DDD는 무척이나 많은 시간이 들기 때문이다. domain은 단순한 software용어가 아니라 business용어이며 해당 프로젝트에 참여중인 이해관계자들이 공통으로 사용해야하는 표현들인 것이다. 따라서 다양한 domain expert들이 참여하여 domain을 선정하고 표현하며, engineer들은 software 그 이상으로 domain의 동작(로직)을 먼저 생각해야한다.