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 → 쉽게 이해할 수 있는 관점으로 표현해야함 일관성 유비쿼터스 언어는 정..

DDD를 공부하는 이유 복잡한 문제를 해결하고 우아한 솔루션을 만들고 신중하게 규칙과 구조, 행동을 만들어서 완전히 새로운 세상을 만든다. 비즈니스 도메인 주요 활동 영역 페덱스 - 배송 서비스 스타벅스 - 커피 아마존 - 클라우드 날방 - 방송? 하위 도메인 비즈니스의 세분화된 영역 - 목표를 달성하기 위해 서로 상호작용하는 도메인 핵심 하위 도메인 경쟁업체와 다르게 수행하고 있는 것 - 모방하기 어려워야한다. 경쟁 우위 자주 변경 될 수 있다. - 한번의 시도로 해결되지 않는다. 사내에서 구현되어야 한다. (전략적인 투자) 우버 - 승차 공유 서비스(같은 방향으로 향하는 손님을 매칭해서 비용을 절감) 구글 검색 알고리즘 - 광고 플랫폼의 중요한 구성요소 날방 - 쇼핑몰에 pip를 붙여서 할 수 있는것..

1월달에 쓰려고 했는데 지금 씁니다. 일단 2022년 쿠버네티스, 엔트미디어를 이용한 송출서버 만들기, 카프카 공부 등 새로운 것을 많이 한 해였던것 같다. 그리고 대기업 이력서를 써보면서 아직 부족하다는 것을 많이 느낀것 같다. [회사에서] 일단 작년에 회고록 쓴것을 보면 불만도 있고 불안도 있어보였다. 하지만 점차 변화하며 괜찮아진것 같다. 2022년 초에 같이 일하는 과장님하고 어느정도 컨벤션같은 틀을 잡고 일을 해서 나름 자기만족하며 일을 했었던것 같다. 하지만 과장님이 퇴사를 하시고 프로젝트 백엔드 관련된 것(소켓 서버 및 여러가지 서버 관리)을 거의 내가 받았다. 다행히 새로 들어온 사람이 있어서 같이 일을 하며 정리해갔다. 그리고 새로 들어온 사람이 20살인데 사실 나보다 경력이 많은…(나는..