ballde

💡 도메인 주도 설계 방법론과 마이크로서비스 아키텍처 패턴의 관계를 탐구 두 패턴간의 상호작용, 효과적으로 설계하는 방법 서비스란? 미리 정의된 인터페이스를 사용해 하나 이상의 역량에 접근하기 위한 메커니즘 요청/응답 모델과 같은 동기식 모델, 이벤트를 제공하는 비동기식 모델 마이크로 서비스란? 자신의 마이크로 퍼블릭 인터페이스(마이크로 프런트 도어)에 의해 정의되는 서비스 마이크로 퍼블릭 인터페이스가 있으면 서비스가 연동하는 다른 시스템 구성요소 모두를 쉽게 이해할 수 있고 기능을 줄이면 변경될 이유가 줄어들고 개발, 관리, 확장이 자유로움 자신의 데이터베이스를 노출하지 않는다. 서비스형 메서드: 완벽한 마이크로서비스? 서비스 하나에 메서드 하나 라는 규칙을 적용한다고 해보자. 어떤 서비스도 다른 서비..

💡 프로젝트가 진행됨에 따라 바운디드 컨텍스트의 경계가 명확해지고 비즈니스 도메인 모델을 효과적으로 보호, 코드베이스는 훌륭한 상태를 유지 ⇒ 이것은 쉽지 않음, 그리고 축적된 기술 부채에 맞서야함 ⇒ 이상적이지 않은 환경에서 도메인 주도 설계 도구와 패턴을 적용하기 위한 전략을 살펴본다. 전략적 분석 현 상황을 이해해야한다. 비즈니스 도메인 파악 비즈니스 도메인은? 고객은 누구? 서비스 또는 가치? 경쟁 회사 등등 모든 핵심 하위 도메인을 식별할 수는 없음 ⇒ 전체 구조를 식별하고 가장 관련있는 하위 도메인에 주의를 기울이자 핵심 하위 도메인 경쟁업체와 차별점 최악으로 설계된 소프트웨어 컴포넌트 찾기 일반 하위 도메인 일반 하위 도메인을 식별하려면 상용 솔루션이나 구독 서비스, 또는 연동할 수 있는 오..

휴리스틱 모든 상황에 맞게 보장되고 수학적으로 검증된 규칙이 아니라 경험에 기반한 규칙이다. 바운디드 컨텍스트 바운디드 컨텍스트의 최적의 크기는 무엇일까? 바운디드 컨텍스트의 경계를 설계할 때 이런 특성을 휴리스틱으로 사용할 수 있다. 넓은 바운디드 컨텍스트의 경계 또는 하위 도메인에 걸친 경계는 그 경계 또는 하위 도메인을 포함하는 모델이 잘못돼도 안전하게 해준다. 적은 비용이 든다 즉 설계할 때는 경계를 넓게 해서 시작해야한다. 비즈니스 로직 구현 패턴 비즈니스 로직의 구현 패턴을 선택하기 위한 효과적인 휴리스틱은 다음과 같다. 어떠한 동작에 대한 심층적인 분석을 요청하였는가? → 이벤트 소싱 모델 적용 하위 도메인의 비즈니스 로직이 복잡한가? → 도메인 모델 복잡한 자료구조를 포함하는가? → 액티브..

모델 변환 커뮤니케이션 하기 위한 다양한 설계 패턴이 있다. 스테이트리스 모델 변환 프록시가 동기식 통신인지 비동기식 통신인지에 따라 다르다. 동기 코드베이스에 변환 로직을 포함하는 것 오픈 호스트 - 유입되는 요청을 처리할 때 발생 충돌 방지 계층 - 업스트림 바운디드 컨텍스트를 호출할 때 발생 API 게이트웨이 패턴과 같은 외부 컴포넌트로 넘기는 것이 효과적일 수도 있다. 비동기 메세지 프록시를 구현할 수 있다.(메세지 구독하는 중개 컴포넌트) 메세지 모델을 변환하는 것 외에도 메세지를 필터링하여 노이즈를 줄일 수 있음 오픈 호스트 서비스를 구현할 때 비동기식 모델 변환은 반드시 필요 비동기 변환을 사용하면 도메인 이벤트를 가로채서 공표된 언어로 변환할 수 있음 ⇒ 캡슐화 잘됨 스테이트풀 모델 변환 ..

비즈니스 로직과 아키택처 패턴 비즈니스 로직 구현을 지원하고 유지보수에 중요 ⇒ 계층형 아키텍처, 포트와 어댑터, CQRS 계층형 아키텍처 프레젠테이션 계층(사용자 인터페이스 계층) 상호작용을 하기 위한 사용자 인터페이스 GUI, CLI, REST API 외부 환경으로부터 요청을 받고 결과를 소통하기 위한 수단 서비스 계층(어플리케이션 계층) 프레젠테이션과 비즈니스 로직 계층 중간 역할 하부 계층을 조율하는 데 필요한 것들을 감싸서 프블릭 인터페이스의 메서드에 상응하는 인터페이스로 노출 퍼블릭 인터페이스 재사용 모듈화 개선 프레젠테이션, 비즈니스 로직 계층 결합도 낮춤 테스트 쉬워짐 비즈니스 로직 계층(도메인, 모델 계층) 비즈니스 로직 구현 액티브 레코드, 비즈니스 로직 패턴 데이터 접근 계층 영속성 ..

도메인 모델 패턴, 이벤트 소싱 도메인 모델 패턴 ⇒ 애그리게이트의 상태를 저장하는 방식이 다르다. 이벤트 소싱 테이블을 보면 일반적으로 순서도는 필요 없게 된다. name status A new_lead B closed c new_lead 현재 상태를 문서화하지만 각 리드가 현재 상태에 도달한 이력을 알 수가 없다. ⇒ 현재 상태만 알 수 있다. 이벤트 소싱 패턴은 데이터 모델에 시간 차원을 도입한다. name status timestamp A closed … A new_lead … B closed … c new_lead … history를 통해서 프로젝션(원하는 시점의 데이터 추출) 할 수 있다. 버전을 적어 활용할 수도 있다. 검색이 유용하다 변경사항을 인지하지 못할 경우 이벤트 소싱을 사용하면 과..

비즈니스 로직 코드를 모델링하고 구현하는 다양한 방법 트랜잭션 스크립트 정의 트랜잭션 스크립트 패턴은 프로시저를 기반으로 시스템의 비즈니스 로직을 구성하며 각 프로시저는 퍼블릭 인터페이스를 통해 시스템 사용자가 실행하는 작업을 구현( 약간 파사드 패턴같다.) 각 작업은 성공하거나 실패할 수 있지만 유효하지 않은 상태를 만들면 안된다. 트랜잭션 동작 구현 실패 전체를 아우르는 트랜잭션 없이 여러 업데이트를 하는 경우 Void aaFacade() { 함수1(); 함수2() } @Transaction 함수1() {} 분산 트랜잭션에서 통합할 수 없는 여러 개의 저장 장치로 작업(약간 msa에서 트랜잭션을 한번에 할 수 없는 경우) 분산 시스템: 데이터 변경 -> 메세지 발행 -> 다른 컴포넌트에 알림 암시적 ..

협력형 패턴 그룹 파트너십 패턴 연동을 하면서 조절 및 협력 커뮤니케이션이 어렵다면 적합하지 않을 수도 있다. ⇒ 지리적으로 멀다. 공유 패턴 커널 서로 다른 바운디드 컨텍스트에 즉시 영향 변경되면 즉시 반영되어야함 ⇒ 프로젝트에 common(공통) 부분 전파하지 않으면 모델의 일관성이 깨지므로 조심 공유 커널 사용 이유 하지만 공유 커널은 중복 비용과 조율 비용을 보고 사용할지 말지 판단해야한다. 바운디드 컨택스트에 위반 사용자 - 제공자 패턴 그룹 순응주의자 패턴 힘의 균형이 제공자에게 있는 경우 조직 외부의 서비스 제공자와 연동하는 경우 외부 API 사용(브로드밴드, 메이크샵?) 충돌 방지 계층 패턴 제공자의 모델을 따르는 것을 원치 않을 경우 다운스트림의 바운디드 컨텍스트가 하위 도메인을 포함할 ..

일관성 없는 모델 ‘리드’라는 용어가 서로 다르게 사용된다. 마케팅 부서 - 제품에 대한 관심 영업 부서 - 영업 프로세스의 전체 생명 주기? 모호성은 의사소통에서는 얘기를 하면서 추론할 수 있어 문제가 되지 않는다. ⇒ 소프트웨어로 표현할 때 문제가 된다. 해결방법 모든 종류의 문제에 사용할 수 있는 단일 모델을 설계하는 것 모든 것에 적합해야하지만 결국 복잡성에 직면하게 됨 용어 앞에 접두사 추가 인지부하 유비쿼터스 언어와 일치하지 않음 → 얘기를 할 떄 접두사 없이 해도 소통 가능하니까. 즉 일관성 있게 얘기를 해야한다. 바운디드 컨텍스트 유비쿼터스 언어를 여러 개의 작은 언어로 나눠서 할당 컨텍스트를 명시적이고 중요한 비즈니스 도메인의 요소로 모델링할 수 있다. 모델 경계 모델의 경계를 정의하는 ..

비즈니스 문제 고객의 문제를 해결하는 솔루션 제공 최적화, 문제 해결 도메인 지식 찾아내기 비즈니스 도메인 지식이 있어야한다. 도메인 전문가를 이해하고 그들이 쓰는 동일한 비즈니스 용어를 사용하는 것이 중요하다. 커뮤니케이션 다른 협력 잡업과 마찬가지로 모든 참여자가 얼마나 잘 협력할 수 있는가? 커뮤티케이션은 성공에 필수 도메인 지식 → 멘탈 모델 → 솔루션 모델 → 코드 문서화된 커뮤니케이션은 최신 정보를 담아내지 못하고 전달 과정에서 손실 유비쿼터스 언어 효과적으로 소통하기 위해 변환에 의존하지 말고 같은 언어를 사용한다. 즉 도메인을 설명하기 위한 단일화된 언어체계가 필요하다. 비즈니스 도메인 전문가에게 디자인 패턴 얘기 X → 쉽게 이해할 수 있는 관점으로 표현해야함 일관성 유비쿼터스 언어는 정..