서론

이번에 DDD에 대한 학습을 위해 기다리던 NextStep에서의 DDD 세레나데 강의를 수강하게 되었습니다.
매번 도메인 주도 설계라는 것을 말로만 이야기 했지 실제 학습을 해보거나 실제 적용을 하려는 모습에서도 내가 하는 방식이 맞는지? 또한 이걸 팀 내에서 이야기하기 위해서 이게 왜 필요하고, 이게 있었을때 더 좋을수 있는지 개발자들뿐 아니라 기획자, 디자이너에게도 이야기를 하려고 할때도 설명이 미흡하다는 생각들이 많이 들었다.
이번 과정에서는 DDD를 어떻게 하면 회사에 적용해볼수 있는지를 고민해보려고 한다.

도메인 주도 설계 이해

들어가며

도메인 주도 설계라는것이 무조건적인 정답이 아니다. 이 부분이 가장 중요하다.
못질을 할때 망치가 필요하고, 나사를 조일때 드라이버가 필요한데, 어떤 사람들은 무조건 망치만 있으면 된다. 라고 생각하는 경향이 있다.
그러나 각 상황에 맞게 필요한 것이 있는거고 또한 더 잘 해결해 나갈 수 있는 것들이 있을수 있다.
그런 관점에서 도메인 주도 설계를 생각해보면 어떨까? 그렇다면 어떤 경우에서는 방해가 되는 요인이 될수도 있다.
- CRUD와 같은 간단한 업무는 훨씬 더 간단한 방법으로 빠르게 해결해나갈수가 있다.
아울러 도메인 주도 설계는 구현 자체가 중요한게 아니다. 중요한건 비지니스 문제에 맞게 코드를 구성하고 동일한 비지니스 용어인 유비쿼터스 언어를 사용하는 것이 가장 중요한것 이다.

클린 아키텍처

천줄을 넘는 메서드를 가지고 있거나, 또한 새로운 요구사항이 추가되거나 버그가 발생할때마다 코드가 4~5줄이 계속 늘어나게 된다. 이럴때마다 코드도 분석해야 하지만, 또한 이런 코드들이 동작하고 있다는 것을 기획자, 디자이너, 다른 동료 개발자들이 아는가? 그런부분들도 계속 확인해봐야 한다.
또한 프론트, 백엔드, DB 등등 동일한 처리를 하는 것이지만 각각 구현되어 있을때도 있고, 코드가 아닌 운영 정책으로도 존재하는 경우들도 있다.
- 각각 구현되어 있다는 것은 예를들어 어느곳은 해당 소수의 반올림, 올림을 하는 것이 프론트에 구현되어 있거나 또는 다른 것은 백엔드에 자바 코드로 구현되어 있거나 혹은 DB로 구현되어 있는 상황을 이야기 하는 것이다.
- 코드가 아닌 운영 정책으로 존재한다는 것은 코드에서는 존재하지 않는데 실제 가이드나 기획 문서와 같은 곳에서는 적혀 있는 경우다. 예를들어, 사용자 이름은 50자를 넘을수 없다. 라고 안내가 되어 있지만 실제 코드에서는 55자를 입력해도 잘 동작하는 그런 상황을 이야기 한다.
따라서 이런 경우에 어떻게 해야 할까? 고민을 하게 되며, 클린아키텍처를 만나게 될수 있다.
- 클린 아키텍처는 비지니스 규칙을 한곳에 모아야된다. 라는 부분으로 코어라고 부르는 엔티티/유스케이스를 바깥의 레이어에 영향을 받지 않게 설계하는 것이 가장 중요한 핵심으로 자리 잡고 있다.

클린 아키텍처는 로버트 C. 마틴이 제안한 좋은 소프트웨어 아키텍처의 보편적인 원칙으로 다음과 같은 특징을 가지고 있다.

이름	설명
프레임워크 독립성	아키텍처는 다양한 기능의 라이브러리를 제공하는 소프트웨어, 즉 프레임워크의 존재 여부에 의존하지 않는다. 이를 통해 이러한 프레임워크를 도구로 사용할 수 있으며, 프레임워크가 지닌 제약사항 안으로 시스템을 욱여 넣도록 강제하지 않는다.
테스트 용이성	업무 규칙은 UI, 데이터베이스, 웹 서버, 또는 여타 외부 요소가 없이도 테스트할 수 있다.
UI 독립성	시스템의 나머지 부분을 변경하지 않고도 UI를 쉽게 변경할 수 있다. 예를 들어 업무 규칙을 변경하지 않은 채 웹 UI를 콘솔 UI로 대체할 수 있다.
데이터베이스 독립성	오라클이나 MS SQL 서버를 몽고DB, 빅테이블, 카우치DB 등으로 교체할 수 있다. 업무 규칙은 데이터베이스에 결합되지 않는다.
모든 외부 에이전시에 대한 독립성	실제로 업무 규칙은 외부 세계와의 인터페이스에 대해 전혀 알지 못한다.

도메인 주도 설계

엔티티는 가장 일반적이며 고수준인 규칙을 캡슐화한다. - 클린 아키텍처

그렇다면 결국 엔티티와 유스케이스를 어떻게 할것인가?를 고민하게 되어야 하며, 그렇게 되었을때 자연스럽게 도메인 주도 설계라는 영역을 만나게 된다.

소프트웨어의 존재 가치

소프트웨어의 본질은 문제를 해결하는 능력에 있다. 아무리 기술적으로 좋다고 한다 한들, 당면한 문제를 해결하지 못한 소프트웨어는 실패한 소프트웨어이다.

따라서 소프트웨어를 만들려면 비지니스라는 사용자 니즈나 문제를 해결하기 위한 것을 이해하고, 관련 지식을 쌓고 본질적 복잡성(essential complexity)과 우발적 복잡성(accidental complexity)을 구별하는 것이 중요하다.

본질적 복잡성(essential complexity) vs 우발적 복잡성(accidental complexity)

본질적 복잡성은 문제 자체에서 발생하며 문제의 범위를 줄이지 않고는 제거할 수 없다. 반면에 우발적 복잡성은 솔루션으로 인해 발생하며 프레임워크, 데이터베이스 또는 기타 인프라가 될 수 있다.

*출처: Why does it take so long to build software?, https://www.simplethread.com/why-does-it-take-so-long-to-build-software*

도메인 주도 설계는 본질적 복잡성을 낮추는 방법에 초점을 맞춰 시스템의 복잡성을 낮출수 있도록 한다.

무엇이 문제인가?

**[우아콘 2021] 도메인 원정대**에서 나온 이야기로 문제를 파악하는것이 가장 중요하다.
개발자라면 기술적인 솔루션을 먼저 찾게 된다. 예를들어 엑셀 다운로드 할 방법을 찾는다거나, 파일 다운로드를 어떻게 구현할수 있는지를 찾게 된다.
결국 문제를 해결 하기 위해서는 무엇이 문제인지, 누구의 문제인지 정의를 내려야 하는 것이 중요하다.
이러한 부분들을 도메인이라고 한다.

도메인

소프트웨어는 사람의 욕망과 욕구를 해결하려고 만든 창조물입니다. 사람들의 욕망과 욕구가 개발자에게 전달됐을 때 우리는 그것을 도메인이라고 부릅니다. - 조영호

도메인은 한마디로 “소프트웨어로 해결하고자 하는 문제 영역”이다.
소프트웨어를 사용하는 사용자는 사용자의 활동이나 관심사와 관련되어 있다. 소프트웨어 산업은 다른 산업 내에서 발생하는 다양한 비지니스 문제를 해결한다. 즉, 우리는 웹애플리케이션을 만들지만 전자 상거래(e-commerce)의 산업에 문제를 해결하는 것이다. 그러기 떄문에 문제를 파악하기 위해서는 전자 상거래의 지식이 필요하게 된다.

도메인 모델

모델이란 목적을 위해 현실세계에 존재하는 것을 가공하고 편집하여 우리에게 정보를 제공하게 된다.
도메인 모델이란 아이디어이자 목적을 가진 의사소통 수단이다. 이 수단은 기획, 디자인, 개발자들이 사용하게 된다.

도메인 주도 설계

현실적으로는 기획자와 개발자 디자이너 모두가 생각하는 도메인 모델이 같은가?
개발자는 요구 사항을 기술 언어로 번역하고 솔루션에 집중하게 되고 이 번역된 언어는 의사소통을 위해 다시 번역해야 하고 이 과정에서 많은 의사소통 비용이 낭비된다.
이 관점에서 도메인 주도 설계는 도메인 모델의 적용 범위를 구현으로 확장하기 위해 도메인을 탐색하고 학습하기 위한 다양한 원칙과 패턴을 제안한다. 그러나 결코 "설계를 하라, 그 다음에 구축하라"가 아니다.

세 개의 기둥

이제 이 3개에 대해 배울텐데, 실제 이 세개 모두가 가장 잘 이뤄져 있어야 하는 것이다. 대부분 전술적 설계만 하고 도메인 주도 설계를 했다. 라고 하지만, 실제 전술적 설계는 이 세개의 관점에서 3/1정도밖게 되지 않는다.
실제 이 모두가 잘 이뤄져 있을때 가장 효과적으로 볼수 있다.

728x90

저작자표시 비영리 변경금지