최근 여유가 생겨 <도메인 주도 설계로 시작하는 마이크로서비스 개발>라는 책을 읽고 있다.
흥미로운 개념들이 많이 나와서 재밌게 읽고 있는데 DDD에 대한 개념이 많이 등장한다.
DDD에 대한 개념은 이전부터 알고 있었지만 추상적인 개념이라고 명확하게 이해하진 못한 것 같다.
개인적으로 어떤 개념이든 이런 수준의 높은 추상적인 개념, 방법론, 패턴, 철학 등은 본인이 직접 써보거나 신중하게 장단점을 판단하지 않은 이상 무턱대고 쓰지 말아야한다고 생각한다.
그래서 이번에 시간을 갖고 DDD 관련 자료를 여러 개 탐색해보고 그 내용을 정리해보고자 한다.
도메인이란?
소프트웨어로 해결하고자 하는 문제 영역이다.
즉 비즈니스 영역이다.
도메인 주도 설계란?
도메인을 중심으로 하는 개발방식이다. 도메인에 관련된 문제를 해결하는게 핵심이다.
복잡한 도메인을 해결하는 것을 높은 우선순위로 생각해서 서비스를 만들어나가는 방식이다.
도메인의 복잡성을 조금 더 쉽게 다룰 수 있게 도와주는 도구라고 볼 수 있다.
소프트웨어 개발과 모델링의 불일치가 발생할 수 있다.
그래서 유비쿼터스 랭귀지라는 게 존재한다. 도메인에 대한 어휘를 이해관계자(도메인 전문가, 개발자, 분석가 ...)들이
공통적으로 의미로 이해할 수 있도록 하기 위함이다.
도메인 모델이란?
도메인에 대한 구체적인 설계, 도메인을 개념적으로 표현한 것이다.
개념들의 관계를 표현한 모델이다.
도메인 주도 개발?
복잡한 소프트웨어는 기술 자체의 복잡성보다는 도메인 자체의 복잡성에 기인한다.
그래서 도메인 전문가와 어떻게 협업할 지가 꽤 중요하다.
유비쿼터스 랭귀지와 모델 주도 디자인이 이 협업을 도울 수 있다.
전략적 설계?
독잡한 도메인의 맥락 경계를 명확히 정의하는 과정이다.
Bounded Context안의 도메인 모델에서 보편 언어를 개발하는 방법이다.
경계를 명확히 하지 않으면 진흙 덩어리 문제가 생긴다고 한다. 그냥 복잡해지는 문제다.
전술적 설계?
전략적 설계에서 더 상세한 부분을 모델링한다.
Bounded Context 내부를 모델링하는거다.
DDD는 패턴보다는 협업을 통한 문제 해결이 더 강조되는 개념이다.
바운디드 컨텍스트?
해결 영역이다.
관심사를 분리하고 격리하여 문제 해결에 집중할 범위를 정한다.
애그리거트?
일종의 캡슐 혹은 비즈니스 규칙이다.
시스템이 기대하는 책임을 수행하며 일관성을 유지하는 단위이다.
일관성은 항상 참이어야 하는 속성을 유지함으로써 달성된다.
명령을 수행하기 위해 함께 조회하고 업데이트해야 하는 최소 단위이다.
결과적 일관성
일시적으로 불변식이 깨지지만 최종적으로 지킬 수 있도록 노력한다.
핵심
누구의 문제인지, 어떤 것이 문제인지, 왜 문제인지에 대한 질문을 던지는 게 좋다.
계층형 아키텍처의 계층을 나누는 것 만큼 해결 영역을 나누는 것도 중요하다.
데이터베이스의 동시성 제어보다 애플리케이션의 동시성 제어가 더 한눈에 들어온다.
도메인 전문가와 함께 모델을 검증하는 것이 코드를 작성하고 테스트하는 것보다 빠를 수 있다.
우테코
https://www.youtube.com/watch?v=VIfNipL5KkU
우아콘2021
https://www.youtube.com/watch?v=kmUneexSxk0
1. DDD에 대한 오해
DDD에서는 전략적 설계가 중요하다. 이게 DDD의 본질이다. 전술적 설계가 아니라 전략적 설계가 중요하다.
큰 그림을 잘 그리는게 DDD에서 가장 중요하다.
DDD는 단순한 소프트웨어에는 적용할 필요가 없다.
DDD는 MSA와 시너지가 날 수는 있지만 무조건 적용할 필요는 없다.
DDD를 패턴 사용법이나 관례, 방법론으로 인식하지마라.
DDD는 오히려 추상적인 철학이나 접근법이 본질이고 그 본질은 전략적 설계에 근간을 두고 있다.
2. 전략적 설계
비즈니스 도메인은 회사의 활동 무대를 말한다. 그 중 일부를 소프트웨어로 해결하고자 할때 그 부분을 문제 도메인이라고 정의한다.
특정 IT회사는 비즈니스 도메인과 문제 도메인이 일치할 수도 있다.
브라운 필드?
이미 구축된 소프트웨어에서 진행되는 프로젝트를 의미한다.
그린 필드?
맨땅에서 새로 만드는 프로젝트를 의미한다.
전략적 설계 시 유용한 도구
- 사용 사례 분석
- 이벤트 스토밍
- Business Model 분석
Ubiquitous-Language가 중요하다.
3. Bounded - Context
Bounded Context가 달라지면 Ubiquitous - language도 달라진다.
콘웨이의 법칙
소프트웨어의 구조는 해당 소프트웨어를 개발하는 조직의 구조를 따라간다.
역콘웨이의 법칙
개발하는 조직의 구조를 소프트웨어의 구조에 맞춘다.
4. Context-Map
Context-Map은 Bounded-Context와 매핑 관계를 그린 다이어그램이다.
5. 진화하는 설계
설계는 수시로 변한다. 그에 맞게 소프트웨어 개선이 지속되어야 한다.
핵심 도메인을 선발하고 거기에 조직의 역량을 부어야한다.
선택과 집중이 중요하다. 그래서 전략적 설계가 중요하다.
6. 정리
도메인 주도 설계는 접근법, 철학이다.
DDD를 예술의 영역으로 본다.
DDD에서 전략적 설계가 중요하다.
지식 탐구와 커뮤니케이션
언제 어디서나 Ubiquitous-Language
NHN FORWARD 22
https://www.youtube.com/watch?v=6w7SQ_1aJ0A
어느 분야에서 10년 일하면 해당 분야 즉 도메인에 어느정도 지식이 정립된다.
도메인 지식을 중점으로 해서 서비스를 만들라는 개념이다.
결론은 OOP랑 얼추 비슷한 개념이다.
왜 근데 굳이 DDD를 할까?
이걸 왜 추앙할까? 이걸 이만큼 맹목적으로 믿을 만한 개념일까?
DB쪽을 많이 만지는 사람들은 세상의 모든걸 DB로 본다.
모든 걸 하나로 뭉치면 도메인이란 개념이 나온다.
DDD는 OOP의 아류작 느낌이었다.
DDD에서 좋은 점은 도메인 드리븐 디자인이라는 이름 즉 명명에서 쓰는 용어들 그걸 실제 비즈니스에서 쓰는 용어를 쓰려고 한다는 점이다.
비즈니스에서 쓰는 용어를 쓰자는 거다. 맞는 얘기다. 좋은 개념이다.
DDD에서 디자인을 할 때 한번에 디자인이 나오진 않는다.
DDD에서는 도메인 분리를 중시한다.
요즘 마이크로서비스가 다시 부각을 받는다.
kim pope
https://www.youtube.com/watch?v=n_9fBLl1gb4
개인적인 견해
결론을 내리면 굉장히 추상적인 개념이다.
이걸 잘 해내는 조직이 있을까라는 의문이 든다.
막상 하겠다고 이야기는 하겠지만 이 철학을 심도있게 고민하면서 지키려 애쓰는 과정에서 오히려 득보다 실이 더 클 가능성이 있다고 생각한다.
소프트웨어 개발에는 이처럼 다양한 방법론, 개념 철학 그리고 권장되는 아키텍쳐가 있다.
처음 들어보고 어려운 개념도 많다. 하지만 개인적인 생각은 이런 철학, 방법론 혹은 아키텍처 등은 내가 필요하다고 느낄때만 써야한다고 생각한다.
남들 다 쓰고 그저 좋다는 말이 많다는 이유에서 무조건 억지로 끼워맞추려 하는 시도가 오히려 효율성을 떨어뜨리고 조직에도 악영향을 줄 수 있다는 생각이 든다.
내가 필요한 것만 골라서 써보고 별로면 버리고 괜찮으면 쓰자.
이게 맞는 길인 것 같다.
관련 자료의 출처는 아래와 같다.
좋은 자료를 제공해주셔서 감사합니다.
kim pope
https://www.youtube.com/watch?v=n_9fBLl1gb4
NHN FORWARD 22
https://www.youtube.com/watch?v=6w7SQ_1aJ0A
우테코
https://www.youtube.com/watch?v=VIfNipL5KkU
우아콘2021
'개발 정보' 카테고리의 다른 글
| [Test] Intellij에서 테스트 시 No tests found for given includes: 에러 발생 (0) | 2023.01.30 |
|---|---|
| [Gradle] gradle 빌드 중 error: unmappable character (0xED) for encoding x-windows-949 발생 (0) | 2023.01.29 |
| [Tech] CORS 란? - Cross origin resource sharing (0) | 2023.01.01 |
| [Tech] WAS와 웹서버의 차이 (0) | 2022.11.12 |
| [Dev] 대용량 파일 전송에 UDP가 적합하지 않은 이유 (0) | 2022.10.24 |