도메인주도설계 (8) 썸네일형 리스트형 [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-1. 전략적 설계 - 비즈니스 도메인 분석하기. Part 1 전략적 설계의 첫 장에서 알아볼 것. 기업이 존재하는 이유와 추구하는 목표가 무엇이며, 그 목표를 달성하기 위한 전략을 배워보자. 보통의 (일단 우리회사 포함) SW개발자의 경우, 코드를 작성하는게 아니라 이러한 것을 알아야하는지 의문을 가질 수 있다. 하지만 업무에 대한 시스템을 개발하기 위해서는 해당 업무에 대한 문제에 대한 이해, 이에 앞서 그것이 존재하는 맥락을 이해할 필요가 있다. 즉, 조직의 비즈니스 전략과 소프트웨어를 만들면서 얻고자 하는 가치를 이해해야 한다. 비즈니스 도메인이란? - 비즈니스 도메인은 기업의 주요 활동 영역을 정의한다. - 일반적으로 말하자면 회사가 고객에게 제공하는 서비스를 말함 ex) 페덱스는 배송 서비스, 스타벅스는 커피, 월마트는 소매업체 - 기업은 여.. [DDD 첫걸음] 1. 전략적 설계 우리가 해결하고자 하는 문제가 무엇인지 합의하기 전에 해결책을 얘기하는 것은 의미가 없다. 또한 해결책에 대해 합의하기 전에 어떻게 구현하는지 얘기하는 것도 의미가 없다. - 애프랏 골드랫 - 아쉬라그 도메인 주도 설계 (DDD - Domain Driven Design)에는 크게 두가지 부분으로 나눌 수 있다. 1. 전략적 측면 - 무엇?과 왜?라는 질문에 대한 정답을 찾는 것. - 우리가 어떤 소프트웨어를 만드는지, 그리고 왜 그 소프트웨어를 만드는지에 대한 해답을 찾는 것. 2. 전술적 측면 - 어떻게?라는 방법에 대한 것. - 소프트웨어 각각의 구성요소가 구현되는 방법을 찾는 것. 이번 장에서는 전략적 측면에 대해서 알아보도록 한다. 전략적 설계 관점에서 알아볼 것. 1. 기업의 비즈니스 전략을 분.. 이전 1 다음
