도메인 주도 설계 구현-애플리케이션
도메인 주도 설계 구현 애플리케이션(Application) 핵심 도메인 모델과 상호 교류하며 이를 지원하기 위해 잘 조합된 컴포넌트의 집합 사용자 인터페이스 도메인 객체 랜더링 애그리게잇 인스턴스로 부터 데이터 전송 객체(DTO) 랜더링하기 애그리게잇 내부 상태를 발행하기 위해 중재자를 사용하자 도메인 페이로드 객체로부터
34 posts
도메인 주도 설계 구현 애플리케이션(Application) 핵심 도메인 모델과 상호 교류하며 이를 지원하기 위해 잘 조합된 컴포넌트의 집합 사용자 인터페이스 도메인 객체 랜더링 애그리게잇 인스턴스로 부터 데이터 전송 객체(DTO) 랜더링하기 애그리게잇 내부 상태를 발행하기 위해 중재자를 사용하자 도메인 페이로드 객체로부터
도메인 주도 설계 구현 바운디드 컨텍스트 통합(Integrating Bounded Contexts) 통합의 기본 1. 하나의 바운디드 컨텍스트가 애플리케이션 프로그래밍 인터페이스(API)를 노출하고 다른 바운디드 컨텍스트가 원격 프로시저 호출(RPC)을 통해 해당 API를 사용하는 방법 2. 메시징 메커니즘을 사용하는 것
도메인 주도 설계 구현 리파지토리(repository) 리파지토리는 보통 저장소의 위치를 말하는데 주로 그안에 저장된 항목의 안전이나 보존을 위한 장소로 여긴다. 이런 기본적인 원리들은 DDD 리파지토리에도 적용된다. 일반적으로 애그리게잇 타입과 리파지토리 사이에는 일대일의 관계가 성립한다. 정확히 말하자면 애그리게잇만이
도메인 주도 설계 구현 팩토리(factory) 도메인 모델 내의 팩토리 팩토리는 도메인 모델 내에서 객체 생성외의 추가적인 책임을 가질수도 있고 그럴지 않을 수도 있다. 애그리게잇 루트상의 팩토리 메소드 신중한 생성 과정을 통해 클라이언트가 짊어져야 하는 부담을 줄이고 모델의 표현력을 얻을수 있다. 서비스의 팩토리 서비스
도메인 주도 설계 구현 애그리게잇(aggregate) 규칙 : 경계의 밖에선 결과적 일관성을 사용하라 하나의 애그리게잇 인스턴스에서 커맨드를 수행할 때 하나 이상의 애그리게잇에서 추가적인 비즈니스 규칙이 수행돼야 한다면 결과적 일관성을 사용하자 큰 규모의 트래픽이 많은 엔터프라이즈에선 애그리게잇 인스턴스가 절대적이고 완전
도메인 주도 설계 구현 애그리게잇(aggregate) 스크럼 핵심 도메인에서 애그리게잇 사용하기 큰 클러스터의 애그리게잇 크기가 큰 애그리게잇은 처음엔 그럴싸해 보이지만 실제론 실용적이지 않다. 의도치 않게 트랜젝션이 주기적으로 실패하는데 실패의 원인은 실제 비즈니스 규칙이 아닌 잘못된 고정자를 기준으로 설계 하여 실패
도메인 주도 설계 구현 모듈(module) 모듈 설계하기 DDD 컨텍스트에서 모델 안의 모듈은 서로 간에 높은 응집도를 갖고 있는 도메인 객체를 담는 이름이 붙여진 컨테이너 역활을 수행하며 각이 다른 모듈에 있는 클래스 사이에 낮은 결합도를 유지하는 것이 목표가 돼야 한다. 모듈 설계의 간단한 규칙 1. 모델링 개념에 맞
도메인 주도 설계 구현 도메인 이벤트(Domain Events) 이벤트 저장소 한 바운디드 컨텍스트에 모든 도메인 이벤트를 하나의 저장소에 유지 관리할때 장점 1. 이벤트 저장소를 큐를 사용해 메시징 인프라를 통해 모든 도메인 이벤트를 발행한다. 2. 폴링 중인 클라이언트에게 REST 기반 이벤트 알림을 전달하기 위해 같
도메인 주도 설계 구현 도메인 이벤트(Domain Events) 도메인 모델에서 이벤트 발행하기 구독자 어떤 컴포넌트가 도메인 이벤트에 구독자를 등록하는가? 일반적으로 애플리케이션 서비스에서 등록이 이뤄지며 때론 도메인 서비스에서도 등록할 수 있다. 헥사고날 아키텍처를 사용할 땐 애플리케이션 서비스가 도메인 모델의 직접적
도메인 주도 설계 구현 도메인 이벤트(Domain Events) 이벤트의 모델링 이벤트를 모델링할 땐 해당 이벤트가 속한 바운디드 컨텍스트의 유비쿼터스 언어에 따라 이벤트와 속성을 명명하 애그리게잇의 커맨드 오퍼레이션 실행에 따른 결과로 그 이름은 보통 커맨드로 부터 파생된다 이벤트가 제공하는 행동적 오퍼레이션은 어떻게
도메인 주도 설계 구현 도메인 이벤트(Domain Events) 도메인이 발생한 사건을 위해 도메인 이벤트를 사용하자. 이벤트는 아주 강력한 모델링 도구이다. 일단 도메인 이벤트를 사용하는 법을 알고 나면 여러분은 이에 중독돼서 어떻게 여지껏 도메인 이벤트 없이 살아 왔는지 의아 해질 것이다. 언제 그리고 왜 도메인 이벤
도메인 주도 설계 구현 서비스(Service) 도메인 내에서 서비스란 도메인 고유의 작업을 수행하는 무상태의 오퍼레이션이다. 도메인 모델에서 서비스를 생성할 필요가 있음을 알리는 가장 정확한 지표는 에그리게잇이나 값 객체 상에 수행해야 하는 오퍼레이션이 메소드로는 부적절하게 느껴질때이다. DDD를 사용하면 이런 전술의 코
도메인 주도 설계 구현 값 객체(Value Objects) 값 객체의 저장 데이터 모델 누수의 부정적 영향을 거부하라. 값 객체를 데이터 저장소로 저장하는 대부분의 경우는 비정규화된 방식으로 저장된다. 즉 해당 특성은 부모 엔터티 객체와 같은 데이터 베이스 테이블 행에 저장된다. 이는 데이터베이스에서 값을 가지고 오는 과
도메인 주도 설계 구현 값 객체(Value Objects) 미니멀리즘으로 통합하기 값 객체를 사용해 유입되는 업스트림 컨텍스트로부터 다운스트림 컨텍스트의 개념을 모델링하자 불변값을 결과로 사용한다면 책임을 덜 수 있다. 값으로 표현되는 표준 타입 여러 시스템과 애플리케이션에선 표준타입이 필요하다. 표준 타입은 대상의 타입
도메인 주도 설계 구현 값 객체(Value Objects) 종종 엔터티에 관한 고민의 그늘에 가려지긴 하지만 값 객체란 DDD의 필수적인 구성 요소이다. 가능한 위치 에서 엔터티 대신 값 객체를 사용해 모델링하도록 노력해야 한다 심지어 도메인 개념이 엔터티로 모델링돼야 할때도 엔터티의 설계는 자식 엔터티의 컨테이너보다는
도메인 주도 설계 구현 엔터티(entity) 엔터티의 발견과 그들의 내부적인 특징 유효성 검사 모델 내의 유효성 검사를 사용하는 주 이유는 하나의 특성/속성, 전체 객체, 객체의 컴포지션 등의 정확성을 확인하기 위해서다 우리는 하나 이상의 단계로 이뤄진 유효성 검사를 통해 가능한 모든 문제를 다뤄야 한다. 특성/속성의 유
도메인 주도 설계 구현 엔터티(entity) 엔터티의 발견과 그들의 내부적인 특징 분명하게 구분된 바운디드 컨텍스트의 유비쿼터스 언어는 도메인 모델의 설계에 필요한 개념과 용어를 제공한다. 엔터티와 속성을 알아내기 팀은 기술적이고 전술적인 모델링의 늪에 빠지길 원치 않는다 토론을 계속한 후에 팀은 단어를 만들어내여 요구사
도메인 주도 설계 구현 엔터티(entity) 고유 식별자 사용자가 식별자를 제공한다. 사용자가 직접 고유 식별자의 세부사항을 입력할때 몇가지 문제점이 있다. 양질의 식별자를 생성하는 일을 사용자에게 의지한다는 점 애플리케이션이 식별자를 생성한다. 고유식별자를 생성하는 식별자 생성패턴 고유 식별자 (UUID) 전역 고유 식
도메인 주도 설계 구현 엔터티(entity) 개발자는 도메인 보다 데이터에 초점을 맞추는 경향이 있다. 소프트웨어 개발에 관한 대부분의 접근법이 데이터베이스에 중점을 두기 때문에 DDD를 처음 접하는 사람에게 일어날 수 있는 현상이다. 풍부한 행동을 바탕으로 도메인 개념을 설계 하지 않고 주로 데이터의 속성과 연결을 먼저
도메인 주도 설계 구현 아키텍처 이벤트 주도 아키텍처 장기 실행 프로세스 실행자와 추적자? 일부 사람들은 실행자(executive)와 추적자(tracker)를 하나의 객체(애그리게잇)의 개념으로 합치는 편이 가장 간단한 접근법이라는 점을 발견했다. 장기 실행 프로세스는 종종 분산 병렬 처리와 관련이 있을 수 있지만, 분산
도메인 주도 설계 구현 아키텍처 커맨드 퀴리 책임 분리(CQRS) 버트랜드 마이어에 의해 고안된 이원리는 다음과 같은 내용을 따르고 있다. 객체 수준에서 이는 다음을 의미 한다. 1. 메소드가 객체의 상태를 수정한다면, 이 메소드는 커맨드이며 값을 반환하면 안된다. 2. 메소드가 값을 반환한다면 이 메소드는 쿼리이며 직접
도메인 주도 설계 구현 아키텍처 REST : 표현 상태 전송 REST는 웹의 아키텍처가 형성된 이후 웹 아키텍처 자체를 기반으로둔 추론을 바탕으로 얻어진 이론적 결과이다. RESTful HTTP 서버의 주요 특징 리소스가 핵심개념이다. 자술적 메시지를 사용해 무상태로 의사소통한다 일부 HTTP 메소드는 멱등한데 이는 오류
도메인 주도 설계 구현 아키텍처 의존성 역행 원리 의존성이 영향을 주는 방식을 조정함으로써 전통적인 계층 아키텍처를 개선하는 방법이 하나 있다. 로버트 C 마틴에 의해 제안되었다. 상위 수준의 모듈은 하위 수준 모듈에 의존해선 안된다. 둘 모두 반드시 추상화에 의존해야 한다. 헥사고날 또는 포트와 어댑터 앨리스테이 콕빈은
도메인 주도 설계 구현 아키텍처 DDD의 가장 큰 장점 중 하나는 특정 아키텍처의 사용을 요구하지 않는다는 점이다. 핵심 도메인이 바운디드 컨텍스트의 중심에 머무르기 때문에 하나 이상의 아키텍처적 영향력이 전체 애플리케이션이나 전체 시스템에 영향을 미칠 수 있도록 해준다. 사용중인 모든 아키텍처의 영향을 정당화하고 정당화
도메인 주도 설계 구현 컨텍스트 맵 컨텍스트 맵이 필수적인 이유 세가지 컨텍스트를 매핑하기 모델의 경우엔 반갑지 않은 방문자 때문에 일반적으로 혼란과 버그를 발생시킨다. 모델러라면 따뜻하게 환영하지만, 질서와 조화를 존중한다는 조건을 지킬 때만 그렇다. 경계에 진입하는 모든 개념은 자신이 갖고 있는 권리를 설명 해야 하며
도메인 주도 설계 구현 컨텍스트 맵 둘 이상의 기존 바운디드 컨텍스트들 사이의 매핑을 보여주는 단순한 다이어그램을 그리는 방법이다. 컨텍스트 맵이 필수적인 이유 DDD를 위한 노력을 처음 시작할때 현재 프로젝트 상황의 시각적 컨텍스트 맵을 먼저 그리자 컨텍스트 맵은 상호 교류해야 할 시스템의 목록 뿐 아니라 팀 내부의 의
도메인 주도 설계 구현 도메인, 서브도메인, 바운디드 컨텍스트 샘플 컨텍스트 모델을 안정적으로 만들수 있는 임시 개선 방안 모델을 책임 계층으로 리팩토링해 보안과 권한 기능을 현존하는 모델 아래의 논리적 계층으로 내려서 구분할 수 있다. 또 다른 대안으로, 분리된 핵심에 맞춰 작업할 수도 있다. 참조
도메인 주도 설계 구현 도메인, 서브도메인, 바운디드 컨텍스트 바운디드 컨텍스트 이해하기 바운디드 컨텍스트는 그 안에 도메인 모델이 존재하는 명시적인 경계 명시적으로 다른 두 모델 내부에선 같거나 비슷한 이름의 객체임에도 서로 다른의미를 갖는 경우가 종종 있다. 두 모델을 명시적인 경계로 둘러싸면 각 컨텍스트 안의 각 개
도메인 주도 설계 구현 도메인, 서브도메인, 바운디드 컨텍스트 왜 전략적 설계가 엄청나게 필수적인가 팀은 반듯이 비즈니스 도메인과 그에 따른 서브도메인은 물론 이고 그들이 개발하고 있는 바운디드 컨텍스을 이해하고 있어야 된다. 현실의 도메인과 서브도메인 도메인은 문제점 공간과 해결책 공간을 모두 갖고 있다. 문제점 공간은
도메인 주도 설계 구현 도메인, 서브도메인, 바운디드 컨텍스트 큰그림 넓은 의미에서 도메인이란 한 조직이 행하는 일과 그 조직 안의 세계를 일컫는다. 조직이 무엇을 어떻게 하는지에 관한 모든 것을 하나의 도메인 모델에 포함해선 안된다 거의 모든 소프트웨어 도메인에는 다수의 서브 도메인이 있다. 서브도메인과 바운디드 컨텍스
도메인 주도 설계 구현 DDD를 시작하며 DDD 적용 난관 일반적인 문제점 유비쿼터스 언어를 만드는 데 드는 시간과 노력을 계산하는 것 도메인 전문가를 시작부터 참여시키고 프로젝트 내내 함께하는것 도메인 내의 해결책에 관한 개발자의 사고방식을 바꾸는것 DDD를 할때는 도메인 전문가의 참여가 필수이다. 많은 개발자가 DDD
도메인 주도 설계 구현 DDD를 시작하며 DDD는 어떻게 하는가 유비쿼터스 언어 : 팀내에 공유된 언어 도메인 전문가와 개발자간에 같이 공유된다. 메소드 명에도 고민을 해서 이름을 정함 해당 부분을 유비쿼터스 언어로 사용하여 코딩 문서도 시간이지나면 수정되지 않는다 코드상의 모델이 가장 지속적이고 유일하게 보장 되는 유비
도메인 주도 설계 구현 DDD를 시작하며 DDD가 해줄수 있는 일 DDD는 도메인 전문가와 소프트웨어 개발자가 비즈니스 전문가의 심적 모델을 반영한 소프트웨어를 함께 개발할 수 있게 해준다. 이팀은 도메인 전문가와 소프트웨어 개발자를 모두 포함하고 절대로 우리와 그들을 나누지 않는다. DDD는 비즈니스의 전략적 이니셔티브
도메인 주도 설계 구현 DDD를 시작하며 도메인 주도 설계라고 불리는 소프트웨어 개발 접근법은 우리가 높은 품질의 소프트웨어 모델을 설계 할수 있도록 해준다. DDD는 전략적인 동시에 전술적인 모델링 도구로서 중요한 비즈니스 목적을 달성시킬 수 있는 양질의 소프트웨어를 설계 할수 있게 해준다. 도메인 전문가는 단순한 직책