본문 바로가기

2022/03

 (33)
도메인을 문서화하기 기술적 구현에 대한 편견을 피하면서, 이러한 요구 사항을 어떻게 기록해야 할까요? 시각적 다이어그램(예: UML)을 사용할 수 있지만 작업하기 어렵고 도메인의 미묘한 부분을 포착할 만큼 충분히 상세하지 않은 경우가 많습니다. 도메인 모델을 코드로 작성하기 전에, 지금은 도메인 모델을 캡처하는 데 사용할 수 있는 간단한 텍스트 기반 언어를 만들어 보겠습니다. 워크플로의 경우 입력과 출력을 문서화한 다음 비즈니스 논리에 간단한 의사 코드를 사용합니다. ​ Bounded context: Order-Taking ​ ​ Workflow: "Place order" ​ triggered by: ​ "Order form received" event (when Quote is not checked) ​ primary i..
데이터베이스 주도 설계, 클래스 주도 설계 피하기 대부분의 개발자는 데이터베이스, 클래스 기반으로 설계하는 경향이 있습니다. 데이터베이스 주도 설계 도메인 주도 설계에서는 데이터베이스 스키마가 아니라 도메인이 설계를 주도하도록 합니다. 현실세계에는 DB라는 개념이 없는 경우도 많습니다. 무엇보다 도메인 전문가들이 DB에 대해서 알아야 할까요? 데이터베이스라는 개념은 확실히 유비쿼터스 언어의 일부가 아닙니다. 사용자는 데이터가 지속되는 방식에 신경 쓰지 않습니다. DDD 용어로 이것을 지속성 무지(persistence ignorance)라고 합니다. 데이터베이스의 데이터 표현에 대해 걱정하지 않고 도메인을 정확하게 모델링하는 데 집중해야 하기 때문에 중요한 원칙입니다. 또한 데이터베이스 관점에서 디자인한다면, 당신은 종종 데이터베이스 모델에 맞게 디자인을..
도메인 전문가와 인터뷰. 서브 도메인의 입출력 하루씩 잡아먹는 이벤트 스토밍 워크샵과 달리, 도메인 전문가와 짧게 여러번 만나 하이레벨로 인터뷰하는것이 좋다. 한번의 만남에 하나의 워크플로 (한 명이 할 수 있는 일, 한 팀이 하는 일)를 다루는 것이 좋다. 하이레벨이란 입력과 출력에만 집중하는 것을 의미한다. (하이레벨 x) 워크플로 : 먼저 제품 코드가 올바른지 체크함. 프로덕트 카탈로그에서 제품을 찾는다. (다른 바운디드 컨텍스트의 가능성) 주문 수량과 제품 가격을 이용해 Cost를 계산함 청구 부서와 배송 부서용 2 개의 사본을 만듬. 원본은 파일에 보관 주문을 스캔하여 고객에게 이메일로 보내 주문 승인 알림 (메일 알림) 주문과 견적의 차이 - 주문과 견적은 둘 다에 대해 동일한 주문 양식을 사용할 만큼 충분히 유사하지만 연결된 워크플로가 ..
유비쿼터스 랭귀지 만들기 우리는 코드와 도메인 전문가가 동일한 모델을 공유해야 한다고 배웠습니다. 이는 우리 설계 안의 무언가가 도메인 전문가의 멘탈 모델의 무언가와 대응되어야 한다는 것입니다. 즉, 도메인 전문가가 무언가를 "주문"이라고 부르는 경우 개발자의 코드에 "주문"이라고 하는 무언가가 있어야 이에 대응하고 동일한 방식으로 동작합니다. 반대로 우리는 도메인 전문가의 모델에서 무언가를 나타내지 않는 것을 디자인에 포함해서는 안됩니다. 이는 OrderFactory, OrderManager, OrderHelper 등과 같은 용어는 없음을 의미합니다. 도메인 전문가는 이 단어의 의미를 모를 것입니다. 물론 일부 기술 용어는 코드베이스에서 발생해야 하지만 디자인의 일부로 이를 노출하는 것은 피해야 합니다. 팀의 모든 사람들이 공..
바운디드 컨텍스트로 솔루션 만들기 솔루션은 도메인의 필요한 정보만 캡처하면 됩니다. 따라서 우리는 "문제 공간"과 "해결 공간"을 구분해야 하며 두 가지 다른 것으로 취급되어야 합니다. 솔루션을 구축하기 위해 문제 도메인의 모델을 생성하고 관련 도메인 측면만 추출한 다음 그림과 같이 솔루션 공간에서 다시 생성합니다. 바운디드 컨텍스트는 구현에서 일종의 서브 시스템입니다. 각 바운디드 컨텍스트는 자체적으로 미니 도메인 모델입니다. 서브시스템보다 바운디드 컨텍스트라는 용어가 적합한 이유는, 시스템 간의 경계를 인식하고, 해당 경계 내에서의 컨텍스트를 인식하는게 중요하기 때문입니다. 왜 컨텍스트라는 용어를 사용하나요? 각 컨텍스트는 솔루션의 일부분의 전문 지식을 나타내기 때문입니다. 컨텍스트 내에서 우리는 공통 언어를 공유하며 디자인은 일관되..
도메인을 서브도메인으로 나누기 "주문 접수 프로세스"의 다양한 측면(주문 접수, 배송, 청구 등)이 분리될 수 있다는 것은 분명합니다. 그것은 우리가 디자인에서 동일한 분리를 따를 수 있다는 매우 강력한 힌트입니다. 이러한 각 영역을 도메인이라고 부를 것입니다. 도메인 주도 설계의 세계에서 우리는 "도메인"을 "일관된 지식의 영역"으로 정의할 수 있습니다. 불행히도 그 정의는 유용하기에는 너무 모호하므로 다음은 도메인에 대한 대체 정의입니다. "도메인"은 "도메인 전문가"가 전문적인 것입니다! 이것은 실제로 훨씬 더 편리합니다. "청구"가 무엇을 의미하는지 사전 정의를 제공하기 위해 애쓰는 것보다 "청구"는 청구 부서의 사람들(도메인 전문가)이 하는 일이라고 말할 수 있습니다. 각 도메인이 겹치는 것을 볼 수 있습니다. 도메인이 약간..
비즈니스 이벤트(도메인 이벤트)를 통해 도메인 이해하기 요구 사항 수집에 대한 DDD 접근 방식은 개발자와 도메인 전문가 간의 공유된 이해 구축을 강조합니다. 그러나 이러한 이해를 발전시키려면 어디서부터 시작해야 할까요? 첫 번째 지침은 데이터 구조보다 비즈니스 이벤트에 초점을 맞추는 것입니다. 비즈니스는 데이터를 정적으로 갖고 있지 않습니다. 비즈니스는 일련의 데이터(도큐먼트) 프로세싱(트랜스폼) 과정입니다. 따라서 데이터들의 변화와 변화 간(함수 간) 관계에 대한 이해가 중요합니다. 또한 어떤 일련의 비즈니스 트리거(이벤트 트리거) - push(publish-trigger) or pull(subscribe-observation)를 이해하는 것이 중요합니다. 이 트리거 역할을 하는 것이 바로 도메인 이벤트입니다. 도메인 이벤트는 우리가 모델링하려는 거의 모..
공유 모델의 중요성(The Importance of a Shared Model) https://fsharpforfunandprofit.com/ddd/ Domain Driven Design | F# for fun and profit This page contains links to the slides, video and code from my talk “Domain Modeling Made Functional”. Here’s the blurb for the talk: Statically typed functional programming languages like F# encourage a very different way of thinking about types. Th fsharpforfunandprofit.com 워터폴의 한계 애자일의 문제점 공유 모델 : 개발팀 / 다른 이해당..

티스토리툴바