본문 바로가기

Design

 (27)
[DDD 첫걸음] 2-5. 전술적 설계 - 커뮤니케이션 패턴 이번 장에서는 단일 컴포넌트의 경계를 넘어 시스템 요소 전반의 커뮤니케이션 흐름을 구성하는 패턴을 알아본다. 바운디드 컨텍스트 간 커뮤니케이션을 용이하게 하고, 애그리게이트 설계 원칙에 의해 부과된 제한 사항을 해결하며, 여러 시스템 컴포넌트에 걸쳐 비즈니스 프로세스를 조율하는 방법을 알아본다. 모델 변환 바운디드 컨텍스트는 유비쿼터스 언어 모델의 경계이다. 서로 다른 바운디드 컨텍스트 사이에 커뮤니케이션 하기 위한 다양한 설계 패턴이 있음. 각기 다른 바운디드 컨텍스트를 구현하는 두 팀이 효과적으로 의사소통하고 협력할 의향이 있을 경우 파트너십을 통해 통합할 수 있음. 프로토콜은 임시방편식으로 조정될 수 있고 모든 통합 문제는 사실상 팀 간의 커뮤니케이션을 통해 해결할 수 있다. 공유 커널은 다른 협력..
[DDD 첫걸음] 2-4. 전술적 설계 - 아키텍처 패턴 이번장 에서는 시스템의 구성요소 간의 상호작용과 의존성을 조율하는 다양한 방법을 살펴본다.비즈니스 로직과 아키텍처 패턴비즈니스 로직은 소프트웨어에서 가장 중요한 요소.하지만 그 외에도 코드베이스에는 입력과 출력, 다양한 저장소에 상태를 저장하고 타 시스템 및 Service provider와의 연동 등의 요소들도 존재. 이렇듯 코드베이스에는 다양한 관심사가 있기 때문에 각 관심사에 맞게 엄격한 구성이 필요하며, 비즈니스 로직이 흩어지는 것을 방지해야함. (유지보수의 용이성)아키텍처 패턴은 코드베이스의 다양한 측면에 대한 구성 원칙을 도입하고 이들 사이의 명확한 경계를 제시.코드 베이스를 조직하는 적절한 방법 혹은 올바른 아키텍처 패턴을 선택하는 것은 단기적으로는 비즈니스 로직 구현을 지원.장기적으로는 유지..
[DDD 첫걸음] 2-3. 전술적 설계 - 시간 차원의 모델링. 도메인 모델 패턴과 동일한 전제를 기반으로 한다. * 복잡한 비즈니스 로직을 갖는 핵심 하위 도메인에 적용. * 밸류 오브젝트, 애그리게이트, 도메인 이벤트 (도메인 모델과 동일한 전술적 패턴)를 사용. 이벤트 소싱 도메인 모델과 도메인 모델과의 차이점 애그리게이트의 상태를 저장하는 방식이 다름. 이벤트 소싱 패턴을 사용하여 애그리게이트 상태를 관리 애그리게이트 상태를 유지하는 대신 모델은 각 변경사항을 설명하는 도메인 이벤트를 생성하고 애그리게이트 데이터에 대한 원천 데이터로 사용. 이번 편에서는 이벤트 소싱을 도메인 모델 패턴과 결합하여 이벤트 소싱 도메인 모델로 만드는 방법을 알아본다. 이벤트 소싱 이벤트 소싱 패턴은 데이터 모델에 시간 차원을 도입한다. 애그리게이트의 현재 상태를 반영하는 스키마 ..
[DDD 첫걸음] 2-2. 전술적 설계 - 복잡한 비즈니스 로직 다루기. 배경 에릭 에반스는 자신의 책에서 비즈니스 도메인의 하위 모델과 코드를 긴밀하게 연결 짓는 데 쓰이는 애그리게이트(aggregate), 밸류 오브젝트(value object), 레포지토리(repository) 등과 같은 패턴을 제시. 이러한 패턴은 종종 전술적 도메인 주도 설계로 불림. 이 패턴이 도메인 모델이고 애그리게이트와 밸류 오브젝트가 그 구성요소이다. 도메인 모델 도메인 모델 패턴은 복잡한 비즈니스 로직을 다루기 위한 것. 복잡한 상태 전환, 항상 보호해야 하는 규칙인 비즈니스 규칙과 불변성을 다룸. 구현 도메인 모델은 행동(behavior)과 데이터(data) 모두를 포함하는 도메인의 객체 모델. DDD의 전술 패턴인 애그리게이트, 밸류 오브젝트, 도메인 이벤트, 도메인 서비스는 모두 객체모델..
[DDD 첫걸음] 2-1. 전술적 설계 - 간단한 비즈니스 로직 구현. 비즈니스 로직은 소프트웨어에서 가장 중요한 부분이며 애초에 소프트웨어를 구현하는 이유이기도 하다. 모든 비즈니스 하위 도메인을 동일하게 만들지 않는다. 하위 도메인마다 전략적 중요성과 복잡한 정도가 다르다. 다소 단순한 비즈니스 로직에 적합한 두 가지 패턴인 트랜잭션 스크립트와 액티브 레코드를 공부해본다. 트랜잭션 스크립트 프레젠테이션으로부터 단일 요청을 처리하는 여러 프로시저를 모아서 비즈니스 로직을 구현하라. - 마틴 파울러 - 구현 각 프로시저는 간단하고 쉬운 절차지향 스크립트(precedural script)로 구현. 저장 장치와 연동하기 위해 얇은 추상화 계층을 사용할 수 있지만 DB 직접 접근도 가능. 각 작업은 성공하거나 실패할 수 있지만, 유효하지 않은 상태를 만들면 안된다! - 트랜잭션 ..
[DDD 첫걸음] 1-4. 전략적 설계 - 바운디드 컨텍스트 연동. 바운디드 컨텍스트 패턴 유비쿼터스 언어의 일관성을 유지 모델링도 가능하게 함. (경계를 명시하지 않고는 모델을 구축할 수 없음.) 경계가 언어의 책임을 구분 짓는다. "하나의 바운디드 컨텍스트 내의 언어는 특정 문제를 해결하는 비즈니스 도메인을 모델링한다." "다른 바운디드 컨텍스트가 동일한 비즈니스 엔티티를 대표할 수 있지만, 이는 다른 문제를 해결하는 비즈니스 도메인을 모델링한다." 다른 바운디드 컨텍스트의 모델은 서로 독립적으로 발전하고 구현될 수 있지만, 다른 바운디드 컨텍스트 자체는 독립적이지 않다. => 독립적으로 발전할 수 있지, 독립적이다 하고는 차이가 있다는 것을 기억. => 서로 다른 바운디드 컨텍스트와 상호작용이 필요하다. 바운디드 컨텍스트 사이에서의 접점은 컨트랙트(Contract)..
[DDD 첫걸음] 1-3. 전략적 설계 - 도메인 복잡성 관리. 우리의 목표는 유비쿼터스 언어를 사용하여 소프트웨어 설계의 의사결정을 내리는 것이기 때문에 언어는 명확하고 일관성이 있어야 한다. 따라서 모호성, 암묵적인 가정, 관련 없는 세부사항이 없어야한다. 하지만 조직의 규모에 따라 도메인 전문가의 멘탈 모델은 일관성이 없을 수 있다. 즉, 같은 비즈니스 도메인에서도 도메인 전문가마다 서로 다른 모델을 사용할 수 있다. 일관성 없는 모델 도메인 전문가의 언어에서 리드(lead)라는 용어가 마케팅과 영업부서에서 서로 다른 의미로 사용됨 예시) 리드 (Lead) 컨텍스트 마케팅 부서 - 마케팅 담당자에게 리드는 누군가가 제품 중 하나에 관심이 있다는 알림을 나타냄. - 잠재고객의 연락처 정보를 수신하는 이벤트는 리드로 간주. 영업부서 - 리드는 영업 프로세스의 전체 ..
[DDD 첫걸음] 1-2. 전략적 설계 - 도메인 지식 찾아내기. 운영환경에 배포되는 것은 도메인 전문가의 지식이 아니라 개발자의 이해 혹은 오해다. - 알베르토 브랜돌리니 이번 장에서는 효과적인 커뮤니케이션과 지식 공유를 위한 도메인 주도 설계 도구인 유비쿼터스 언어를 배우고, 유비쿼터스 언어를 통해서 비즈니스 도메인의 복잡성을 배우며 책 후반부에서 비즈니스 로직을 소프트웨어 모델로 만들고 구현하는 데 이를 활용한다. 비즈니스 문제 우리가 개발하는 소프트웨어 시스템은 비즈니스 문제를 해결하는 솔루션이다. 비즈니스 도메인의 컨텍스트에서 '문제'의 의미는 광범위하다. (워크플로와 프로세스 최적화, 수작업 최소화, 자원관리, 의사결정 지원, 데이터 관리 등과 관련한 과제일 수 있음.) 기업의 목표는 고객의 문제를 해결하는 솔루션을 제공하는 것이다. 도메인 지식 찾아내기 효..

티스토리툴바