본문 바로가기

DDD88

숲과 나무 전략설계숲Context Map 이 전체 숲을 보는 지도MSA의 Outer Architecture전술설계나무CM의 각 BC가 나무에 해당되고 그 나무 설계에 해당하는 것인 전술설계MSA의 Inner Architecture 2024. 7. 31.
BC/UL/CM 바운디드 컨텍스트는 도메인 모델을 적용할 수 있는 개념적인 경계다. 이는 팀에서 이야기를 위해 사용하며 신중히 설계된 소프트웨어 모델 안에서 표현되는 유비쿼터스 언어를 위한 컨텍스트를 제공한다.  - Implementing Domain-Driven Design 도메인 주도 설계 구현, 반 버논 p44 2024. 7. 31.
DDD용어 및 약어 UL : Ubiquitous LanguageCore DomainSub DomainModel Driven Design전략설계BC : Bounded ContextCM : Context MapShared KernelConformistACL : Anti Corruption Layer 전술설계Layered ArchitectureEntityVO : Value ObjectServiceModuleAG : AggregateFactoryRepository 2024. 7. 31.
BC : UL = 1 : 1 DDD의 주춧돌 중 하나인 유비쿼터스 언어 …유비쿼터스 언어는 단일 바운디드 컨텍스트의 경계 안쪽에서 적용하게 된다.여러분은 도메인 모델링 사고방식에 익숙해져야 한다.여러분의 소프트웨어 모델이 전술적으로 어떻게 설계됐든,전략적으론 바운디드 컨텍스트에 따라 명시적으로 모델링된 깔끔한 유비쿼터스 언어를 반영해야 함을 기억하자 - Implementing Domain-Driven Design 도메인 주도 설계 구현, 반 버논 p44 UL이 아직도 무엇인지 잘 모르겠지만 아무튼 DDD의 큰 축중의 하나인 만큼 중요한 요소임은 확실하고 도메인 모델링의 중요한 요소중 하나임BC안쪽에 위치하므로 BC : UL = 1 : 1 로 적용되어야 함(여러 BC에서 동일한 UL을 사용할 수 없음, 그러면 혼란스러움) 2024. 7. 31.
Ubiquitous Language 란 에반스가 소프트웨어 개발 커뮤니티에 기여한 단 하나의 ‘발명’을 꼽아야 한다면,  그건 바로 유비쿼터스 언어다. … 이는 특정 핵심 비즈니스 도메인의 개념과 용어를 소프트웨어 개발 모델로 포착해야 하는 팀을 위한 패턴이다.이 소프트웨어 모델은 명사나 형용사, 또는 동사를 비롯해 한 명 이상의 비즈니스 도메인 전문가가 포함된 개발 팀에서 공식적으로 언급되는 좀 더 풍부한 표현까지 포함한다. 하지만 이 모델이 단순히 단어의 나열에 한정된다고 결론 내린다면 이는 잘못된 판단이다.(프로젝트별 표준 단어, 용어만 관리한다고 되는게 아니라는 의미)… 유비쿼터스 언어도 여러분이 함께 일하는 비즈니스 도메인 전문가의 머릿속 모델을 반영한다. 따라서 모델이 도메인의 원리를 제대로 담고 있는지를 확인할 소프트웨어와 테스트.. 2024. 7. 31.
전술설계 Ch1. 나에게 도에민 주도 설계는 > 전술설계 p34 34페이지의 그림 도메인의 모델의 세부사항들을 그리기 위해 얇은 붓을 사용하는 것과 같음 Entity, Value Object, Aggregate 포함 DDD는 도메인을 명확한 방법으로 모델링 Domain Event의 사용은 명확하게 모델링하는 것을 도와주고, 도메인에 발생한 것에 대해 알아야 하는 내용을 시스템과 공유, 공유할 대상이 로컬의 BC일수도 원격의 BC일수도 있음 - Domain-Driven Design Distilled, p34 2024. 7. 31.
전략설계 Ch1. 나에게 도에민 주도 설계는 > 전략설계  32페이지의 BC 그림 전략설계 : 세세한 구현으로 들어가기에 앞서 두꺼운 붓 터치처럼 사용 (즉, 상세설계 전 분석의 서비스 정의 또는 기본설계를 의미) 비즈니스상 전략적으로 중요한 것, 중요도에 따라 일을 나누는 방법, 통합하는 최적의 방법 Bounded Context라는 전략적 설계 패턴을 사용해서 도메인 모델을 분리 BC안의 보편언어를 개발하는 방법 포함(이 역시 도메인 전문가의 참여를 강조) Sub Domain, Context Mapping, Context Map 을 통한 통합 방법 포함  - Domain-Driven Design Distilled, p33 2024. 7. 31.
전략설계와 전술설계 일반적인 프로젝트는 분석, 설계, 구현, 테스트 등의 단계로 나누지만, DDD에서는 크게 2단계로 나눈다. 전략설계 (Strategic Design)와 전술설계 (Tactical Design)이다. 제가 DDD의 개념도 제대로 몰랐을 때, 전략설계/전술설계라는 단어부터 들었다. 전략이고 전술이고 당연히 무슨 의미인지 몰랐고, 무엇이 먼저인지도 헷갈렸다. 우선 사전적 정의부터 보자. 전략(戰略)「명사」『군사』전쟁을 전반적으로 이끌어 가는 방법이나 책략. 전술보다 상위의 개념이다.- https://stdict.korean.go.kr 국립국어원 표준국어대사전  전술(戰術)「명사」『군사』전쟁 또는 전투 상황에 대처하기 위한 기술과 방법. 장기적이고 광범위한 전망을 갖는 전략의 하위 개념이다.- https://s.. 2024. 7. 31.
DDD 그리고 MSA https://www.youtube.com/watch?v=DOpt6IWU6LU&t=2s 2022. 11. 24.
Ubiquitous Language 적용 전 후 (2) 병원비 영수증을 보면 '급여', '비급여' 항목으로 표시된다. 언뜻봐서는 이해가 잘 되지 않는다. 그런데 그 표시를 '본인부담금', '공단부담금' 으로 하면 훨씬 이해하기 쉽다. '급여(給與) : 돈이나 물품 따위를 줌. 또는 그 돈이나 물품' 라는 뜻과 같이 소비자가 아닌 제공자, 즉 공단입장에서 구분하는 용어로 표기했기 때문이다. 물론 급여항목중에서도 전액본인부담금 등으로 세부적인 구분이 나눠지긴 하지만 환자 입장에서, 돈을 내야하는 소비자 입장에서 그러한 구분이 무슨 의미가 있겠는가? 국민건강보험공단과 병원이 알아서 할 문제이지 소비자는 별 관심없는 어렵고 헤깔리는 용어를 영수증에 표시해서 무엇하겠는가? 프로그램 설계와 개발도 마찬가지다. 개발자가 작성하는 코드도 Provider 입장에서만 생각하기.. 2022. 10. 10.
Ubiquitous Language 적용 전 후 DDD를 이해하는데 여러가지 개념이 있지만 그중에서도 제일 어려운 것 중의 하나가 Ubiquitous Language(UL) 다. 그런데 지금 참고하고 있는 IDDD 책에서도 'DDD의 가장 강력한 요소중 하나'라고 표현하고 있다. 번역하면 '보편언어' 정도 되는가 본데 더 이해하기 어렵다. 무엇이 보편적이라는것인지... 그리고 수많은 사이트에서도 교집합 또는 접점이되는 비슷한 그림으로 줄기차게 설명하고 있지만 여전히 이해되지 않기는 마찬가지다. 그렇게 중요하다고 강조하는데 이해도 잘 안되고, 프로젝트 현장에서는 더더욱 뭐가 UL이고 어떻게 적용한다는것인지..., 그러던 차에 이책의 아래 예를 보고 많이 느꼈다. '간호사가 독감 백신을 표준 용량으로 환자에게 투여한다' 라는 상황을 표현하면 어떨까? //.. 2022. 9. 23.
DDD 적용 전후 MSA에서 그 첫단추는 바로 서비스를 식별하고 검증하는 것이다. MSA 구현에 관련된 기술적인 자료는 많지만 논리적으로 또는 뭔가 근거와 협의를 통해 서비스를 식별하는 것에 대한 내용은 그리 많지 않다. 식별/검증 방법이 여럿 있겠으나 그중에서도 DDD의 개념을 많이 가져다 이야기한다. 마치 DDD를 모르면 MSA를 할 수 없는듯한 느낌을 받을때도 있다. DDD에 대해서도 많은 자료가 있지만, 그중에서도 전략설계, 전략설계중에서도 Sub Domain, Bounded Context, Context Map 등 개념을 통해 정리해가다보면 그게 바로 MSA에서 원하는 Microservice와 많이 닮게 된다는 이야기인듯하다. 하지만 처음 접하는 사람의 입장에서는 어렵다. 위에서 언뜻 이야기한 몇몇 용어만으로도 .. 2022. 9. 23.
MSA공정과 DDD 서비스 정의 워크샾 DDD 전략설계 Event Storming * 간단한 Notation과 절차로 업무 전문가, IT 전문가 누구나 쉽게 이해할 수 있음 * DDD, MSA 개념을 몰라도 참여 가능 * ASIS, TOBE 업무 파악에 집중 Core/Sub Domain Domain Event * 다양한 색, Notation, 절차 복잡 * Command/Event 의 기계적인 표현 * Aggregate 등 이해하기 어려움 개념 * 전략설계와 전술설계 개념 혼재 (후보) Microservice 식별 서비스 식별 기준 + 목표를 바탕으로 개개인의 의견을 종합하여 수보 서비스로 합의 Bounded Context(BC) Bounded Context 식별 기준 (연관도) 검증 * 서비스 간의 API/Publishe.. 2022. 9. 5.
DDD로 가이드해 주실 수 있죠? DDD 적용 해야되는거죠? MSA를 도입하겠다는 또는 도입할 계획이 있는 고객사들이 종종 묻는 질문이다. 고객사들보다 MSA에 대한 이해가 어느정도 있는 개발자들이 이렇게 물어볼 때가 더 많다. 'DDD로 가이드해 달라', 'DDD를 적용해 달라', DDD로 뭘 해달라는 걸까? 보다 구체적으로 물어봐도 정확하게 질문하는 사람이 많지 않다. 그렇다면 MSA를 하겠다는 곳에서 DDD로 뭘 해달라는 건지 그 의도를 먼저 파악할 필요가 있다. 위와 같이 DDD는 크게 전략설계와 전술설계로 나뉘고, DDD를 적용한다고 해서 전략부터 전술설계를 모두 적용할 필요가 없다. 필요한 단계에 필요한 것만, 필요한 장점만 취해도 충분하다고 생각한다. 그렇다면 위와 같이 DDD를 적용해 달라는 질문의 의도는 무엇일까? 전략설계만 적용하겠다는것인지, 전.. 2022. 8. 19.
반버논 DDD Distilled 도메인 주도 설계 핵심 --------------------------------------------------------------Ch2. BC 및 UL과 전략설계BC내에서 UL을 모델링하는 것(업무 전문가들의 해당 도메인에 대한 설명을 개발자와 공유하고 도메인의 언어로 그 내용을 모델링으로 표현)BC- 동일한 Context의 범위를 표현- 이 Context 범주 내에서 SW 모델의 각 Component는 특정한 의미를 갖고, 특정한 일을 수행한다는 의미- BC내 존재하는 Component들은 Context에 특화돼 있으며, Context 안에서 의미가 살아남- BC는 모델이 구현되는 곳이고 BC마다 각각 분리된 SW산출물이 나옴  (BC별로 별도 모델, 설계, 구현, 즉 물리적으로 WAS, DB가 분리됨을 암시)UL- 팀.. 2021. 10. 15.
15장_디스틸레이션 (Distillation 사전적 의미 : 증류, 증류물, 정수) 디스틸레이션 : 혼합된 요소를 분리해서 본질을 좀 더 값지고 유용한 형태로 뽑아내는 과정 모델은 지식의 정수를 추출한 것 - p427 화학적인 증류과정을 거치는 것과 마찬가지로 Sub Domain과 Coherent Mechanism(응집력 있는 매커니즘) 로 분리 이러한 노력은 Core Domain (SW를 차별화하고 구축할 가치가 있게 만들어 주는 부분) 을 추출하는데 목적 그림 15-1 전략적 디스틸레이션에 대한 Navigation Map - p429 Core Domain(핵심 도메인) 이해하기 힘든 시스템은 변경하기도 어렵다. 위험한 요소는 도메인에 대한 큰 그림을 잃게 됨으로써 야기된다. 설계 측면의 우선순위를 매겨야함 도메인 모델을.. 2021. 10. 12.
14장_모델의 무결성 유지(Bounded Context) 4부 전략설계 전략설계 : 모델링 과정을 매우 복잡한 도메인까지 확장하는 원리를 제시 - p354 기업 시스템의 목표 : 전체 업무를 아우르는 긴밀하게 통합된 시스템 통합의 이점을 잃어버리지 않으면서도 모듈화를 달성해서 갖가지 시스템이 다양한 업무 활동을 위해 조화롭게 상호작용하게끔 만드는것은 쉽지 않다 - p354 전략설계 원칙 - p354 - 상호운용성(Interoperability)과 상승효과(Synergy)를 잃지 않으면서 각 부분 간의 결합도는 낮추고 명확화 - 모델에 촛점을 맞춰 시스템의 개념적 핵심, 즉 시스템의 비전을 포착해야 Context : 분명하게 드러나지 않지만 실제로는 가장 근본적인 설계 원칙 - p354 성공적인 모델 : 규모와는 상관없이 모순되거나 정의가 겹치지 않고 처음부터 .. 2021. 10. 8.
09장_암시적인 개념을 명확하게 심층모델에 사용자 행위(Operation), 문제, 문제의 해법에 대한 본질적인 지식을 간결하고 유연하게 표현하는 중심 개념과 추상화가 담겨있다 심층모델로 향하는 첫걸음은 일단 도메인의 본질적인 개념을 모델 내에 표현하는 것 (UML? 어떤 방법으로 표현할 것인가?) - p217 (도메인 전문가와 논의를 통해 예를들어) '발생 Accrual'이라는 용어(가 등장하면)를 모델과 UL에 추가 (어디에 어떻게 추가? 용어사전에?) - p231 Specification 명세 - p238 2021. 10. 7.
08장_도약 가장 어려운일은 도메인 전문가의 관심사를 포착하고 효과적인 설계를 이끌어줄 명확한 모델을 발견하는 것 (이 모델이 무엇인가? 책과 같은 Class Diagram? ES? 요구사항? 기능분해? 업무흐름도?) 도메인에 대한 심층적인 이해를 반영하는 모델 > 도메인 전문가의 사고방식과 융합되고 사용자의 요구에 기민하게 대응할수 있는 SW개발 가능 - p198 Refactoring : SW의 기능을 수정하지 않고 설계를 다시 하는 것 - p198 항상 모든것이 정상적으로 동작하는 상태를 유지하면서 작언 단계를 밟아가며 코드를 개선해야 - p211 사전에 모든 결정을 내리기보다는 기존의 기능은 유지한 채 끊임없이 코드를 변경하면서 설계를 좀 더 유연하게 개선하거나 이해하기 쉽게 만들다 자동화된 테스트가 준비되어 .. 2021. 10. 7.
07장_언어의 사용(확장 예제) 요구사항과 구현 쟁점을 다루고 MDD를 발전시켜 가면서 이어지는 모델과 설계의 정제 과정을 단계적으로 밟아나감으로써 MDD의 적용효과와 2부에서 소개한 패턴이 어떻게 요구사항과 구현 쟁점을 해결할 수 있는지 보여주는 Chapter - p169 도메인 격리 Entity와 VO 구분 연관관계 설계 Aggregate Boundary Repository 선정 Repactoring Module 타 시스템과의 연계 (여기서 소개되는 해운모델이 설명하기 어렵다면 주문, 주문상세 등 일반적으로 이해하기 쉬운 예를 바탕으로 지금까지 나온 개념을 하나씩 설명해보는것도 좋을듯) 2021. 10. 7.
06장_도메인 객체의 생명주기(Aggregate, Factory, Repository) 모든 객체에는 생명주기가 있다 한 객체는 생성되어 다양한 상태를 거친 후 결국 저장되거나 삭제되면서 소멸한다 - p127 도메인 객체의 관리와 관련된 문제(와 해결 패턴 3가지) - p128 1) 생명주기 동안의 무결성 유지 2) 생명주기 관리의 복잡성으로 모델이 난해해지는 것 방지 위의 문제를 아래 3가지 패턴을 이용해 해결 06-1) Aggregate 집합체 : 소유권과 경계를 명확히 정의, 객체간의 연관관계가 혼란스럽지 않도록 생명주기 전 단계에 걸쳐 모데인 객체의 무결성을 유지하는데 매우 중요 06-2) Factory : 생명주기 초기단계, 복잡한 객체와 Aggreage를 생성하고 재구성, 내부 구조를 캡슐화 06-3) Repository : 생명주기 중간과 마지막, Infrastructure를 .. 2021. 10. 7.
10장_유연한 설계 (설계의 여러 패턴을 설명하는 장) 개발이 진행될수록 현재의 레거시 코드로 인한 중압감에 시달리지 않고 프로젝트 진행을 촉진하려면 변경을 수용하고 즐겁게 작업할 수 있는 유연한 설계(Supple Design)가 필요하다 너무 과도한 추상 계층과 간점 계층이 존재하면 오히려 유연성을 방해 사용자에게 유용성을 제공하는 (좋은) 설계는 단순하다. 단순하다는것이 쉽다는 것을 의미하지는 않는다. 조립가능하고 그럼에도 이해가기가 어렵지 않은 요소를 만들어내려려면 MDD를 적당한 수준의 엄밀한 설계 형식과 접목하고자 노력해야한다. SW를 유연하게 만드는 특별한 공식 같은 것은 없지만 개인적인 경험을 바탕으로 적절하게 적용할 경우 유연한 설계를 만들 수 있는 패턴 집합을 추려보았다 그림10-1 유연한 설계에 기여하는 .. 2021. 10. 7.
05장_소프트웨어에서 표현되는 모델(Entity, VO, Service, Module) 여러 모델 요소 가운데 모델을 표현하는 세가지 패턴, 즉 Entity, Value Object(VO), Service를 구분하는 데 초점을 맞춰 설명하겠다 - p83 어떤 객체가 연속성(Continuity)과 식별성(Identity)을 지닌것을 의미하는가? 아니면 다른 뭔가의 상태를 기술하는 속성에 불과한가? 이것은 Entity와 VO를 구분하는 가장 기본적인 방법이다. ... Service는 Client요청에 대해 수행되는 뭔가를 의미한다. ... 기술적인 측정 수단으로 여겨지는 높은 응집도(High Cohesion)와 낮은 결합도(Low Coupling)라는 개념은 도메인 개념에도 적용할 수 있다. MDD에서 Module은 모델의 한 부분이므로 도메인의 개념을 반영해야 한다 - p84 Entity (.. 2021. 10. 5.
04장_도메인의 격리(Layered Architecture중 Domain) 이 책에서 제시하는 설계방식은 대부분 "책임 주도 설계 (Responsibility Driven Design)" 의 원칙을 따른다 - p66 Model Driven Design의 언어로 구성된 Navigation Map - p67 express model with 모델을 표현하는 데 활용 isolate doamin with 모델을 격리하는데 활용 mutually exclusive choices 상호배탁적인 선택 access with 접근하는데 활용 maintain integrity with 무결성을 유지하는데 활용 act as root of 루트 역할을 함 encapsulate with 캡슐화하는데 활용 Layered Architecture 계층형 아키텍처 - p70 계층화의 핵심원칙은 한 계층의 모든 .. 2021. 10. 5.
03장_모델과 구현의 연계 (Model Driven Design) 다이어그램은 벽 크기만큼이나 압도적이어서 이모델에는 분명 상당한 지식이 포함돼 있었다. ... 학습 방향을 잡기가 힘들었는데, 이건 마친 웹을 무작위로 돌아다니는 것과 흡사했다. 하지만 더욱 난감했던 점은 이렇게 학습한 내용이 애플리케이션 코드와 설계에 어떠한 통찰력도 줄 수 없다는 점이었다. ... 데이터 저장소와 같은 클래스명과 속성명을 일부 사용하긴 했지만 그 설계는 기존 모델 또는 어떠한 모델에도 근거하지 않은 것이었다. 프로젝트에 도메인 모델은 있었지만 동작하는 소프트웨어를 개발하는 데 직접적으로 도움을 주지 않는 한 종이에 기록된 모델이 무슨 의미가 있겠는가? - p45 ~ 46 도메인 주도 설계에서는 초기 분석 단계에 도움이 될 뿐 아니라 설계의 기반이 되는 모델이 필요하다 - p46 설계 .. 2021. 10. 5.
02장_의사소통과 언어사용(Ubiquitous Language 보편언어) Ubiquitous Language 보편언어 Ubiquitous(사전적 의미 : 어디에나 있는, 아주 흔한) 공통 언어가 없는 프로젝트에서는 개발자가 도메인 전문가를 위해 자신들의 언어를 번역해줘야한다. 마찬가지로 도메인 전문가도 개발자 가의, 그리고 다른 도메인 전문가 간의 언어를 번역해줘야한다. - p25 프로젝트에서 사용하는 언어가 분열되면 심각한 문제가 발생한다. 도메인 전문가는 자신의 전문용어를 사용하고 기술적인 업무를 맡은 팀원들은 설계 측면에서 도메인에 관한 토론에 적합한 자신들만의 언어를 사용한다. 일상적인 토론에서 쓰이는 용어가 코드에 녹아든 용어와 단절된다. - p25 모델을 언어릐 근간으로 사용하라. 팀 내 모든 의사소통과 코드에서 해당 언어를 끊임없이 적용하는데 전념하라. 다이어그램.. 2021. 10. 1.
00_서문 옮긴이의 글 - 2011년 7월 이대엽 여기서 소개하는 특정 패턴이나 기법을 일률적으로 적용하거나 쓴다고 해서 도메인 주도 설계를 적용한 프로젝트가 되는 건 아니다 복잡한 도메인에서 사용되는 SW를 개발하는 프로젝트가 이 책의 내용을 적용하기에 적격이다 추천의 글 - 2003년 4월 마틴 파울러 복잡함을 통제하는 역쇠는 좋은 도메인 모델에 있다 도메인 모델을 제대로 만들수 있는 사람은 거의 없으며, 가르치기도 아주 어렵다 도메인 모델링에서는 개념과 구현을 분리해서는 안된다 추천의 글 - NHN Business Platform 조영호 SW의 복잡성은 기술적인 이슈보다는 SW가 발을 디디고 있는 문제 도메인에서 기인합니다 모든 SW의 복잡성은 도메인에서 기인한다. 도메인의 복잡성을 해결하기 위해 적용할 수 .. 2021. 10. 1.
01장_지식탐구 Domain : 사용자가 프로그램을 사용하는 대상 영역 - p2 사용자 활동에 도움이되는 SW를 만드기 위해 개발팀은 사용자의 활동과 관련된 지식, 체계에 집중해야 - p3 (이를 위한 수단으로 Event Storming이나 요구사항 분석 등을 업무전문가와 함께 정의, 지속 발전) Model : 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태 - p3 모델과 구현의 연결은 유지보수와 계속되는 기능개선에도 도움이 되는데, 그 이유는 바로 모델을 이해한 바에 근거해 코드를 해석할 수 잇기 때문이다 - p3 SW의 본질 : 사용자를 위해 도메인에 관련된 문제를 해결하는 능력 - p4 그런데도 이러한 도메인 연구는 대부분의 SW프로젝트에서 최우선 과제로 여겨지지 않는다 대부분의 유능한 개발자는 다뤄야할 특.. 2021. 9. 30.

티스토리툴바