silver's develop note

DDD에는 전략적 설계와 전술적 설계라는 개념이 존재한다. 그 중 DDD 의 핵심이라고 말할 수 있는 전략적 설계에 대해 작성해본다. (유튜브 영상 "[NHN FORWARD 22] DDD 뭣이 중헌디?" 와 "도메인 주도 설계로 시작하는 마이크로서비스 개발" 서적을 참고하였다. ) 설계 전략적 설계 전술적 설계 범위 전반적 특성 바운더리 컨텍스트 목적 문제 도메인을 해결영역으로. 풍부한 도메인 모델 적용 메타포 전쟁에서 전략 전투에서 전술 주요패턴 바운터리 컨텍스트, 유비쿼터스 언어, 애그리거트, 도메인 이벤트 수행 방식 접근법 상대적으로 방법론에 가까움 DDD의 전략적 설계 비지니스 응집성을 고려하여 컨텍스트를 구분하고 나누어 설계한다. 컨텍스트는 어디서부터 시작이 되는 걸까? 비지니스 도메인에서 발생..

컨텍스트 맵? 시스템을 구성하는 컨텍스트 간의 매핑 관계를 표시한 다이어그램. 컨텍스트 맵을 그리는 정형화된 규칙은 따로 없는 것 같다. 팀에서 서로 이해할 수 있게 정의하고 표현하면 될 것으로 보인다. 그러나 각 컨텍스트 사이에 존재하는 개념을 이해하고 있어야 컨텍스트 맵을 그릴 수 있기 때문에, 사용하게 되는 각 개념에 대해 소개한다. 컨텍스트 맵 그리는 방법 컨텍스트 맵에서 사용되는 표기 패턴. 공유 커널(Shared Kernel) 두 개 이상의 컨텍스트 사이에 공통적인 모델을 공유하는 관계. ex) 공통 라이브러리 Tip : 공유 커널에 해당하는 부분에서 변경사항이 발생할 경우, 여러 컨텍스트에 영향을 미치기 때문에 한 팀에서 관리하고 공유하는 것이 좋다. 소비자-공급자(Customer-Suppl..

이벤트 스토밍(Event Storming) 구성원이 모두 모여, 벽이나 화이트 보드 같은 넓은 공간에 포스트잇(메모지)를 붙여가며 비지니스에서 발생할 수 있는 여러 이벤트들을 정리하는 브레인 스토밍으로 알베르토 브란돌리니가 고안해낸 설계 기법이다. 각 정의 개념마다 원하는 색깔을 지정하여 한 눈에 보기 좋게 구분한다. 정의할 개념들. (색상은 알베르토 브란돌리니가 정의한 색상들이다. 색상이 중요하다기보단, 내용이 중요한 것이니 조직에서 원하는 바가 있다면 변경하여도 무관할 것.) 도메인 이벤트 발생한 사건. 과거시제동사로 표현한다. 오렌지색 커맨드 도메인 이벤트를 트리거하는 명령. 파란색 외부 시스템 도메인 이벤트가 호출하거나 괜계가 있는 레거시 or 외부 시스템 분홍색 액터 개인 or 조직의 역할 노란..

아키텍처를 설계하고, 좋은 코드를 작성하는 방법에 대해 고민하는 과정들은 결국 "좋은" 소프트웨어를 구현하기 위한 것일 것이다. 그렇다면 아키텍처를 구상해보기 전에, "좋은" 소프트웨어란 무엇일까에 대해 집어보자. 좋은 소프트웨어 시스템? 소프트웨어의 가치는 행위 가치와 구조 가치로 나뉘고, 소프트웨어를 정말로 부드럽게(Soft) 만드는 것은 구조 가치이다. Clean Architecture - Robert C. Martin ☝ 행위 가치 : 소프트웨어의 기능 ☝ 구조 가치 : 소프트웨어 아키텍처 로버트는 코드와 설계의 구조를 깔끔하게 만들려는 생각을 하지 않고 기능 구현만 목적으로 삼으면 소프트웨어가 엉망이 된 상황에 대처하는 데 더 많은 비용이 든다며 구조 가치. 즉, 아키텍처 설계에 대한 중요함을 ..

2-1 에 이어 작성한다. (https://silvers-dev-note.tistory.com/46) 2.3~2.4 마이크로서비스의 아키텍처와 패턴 외부 아키텍처 인프라 영역, 플랫폼 영역, 애플리케이션 영역 내부 아키텍처 비지니스 애플리케이션(백엔드 서버 구성이라고 볼 수 있다.) 마이크로서비스를 구현하기 위한 방법과 패턴 크게 인프라, 플랫폼, 애플리케이션. 이렇게 3가지 단으로 나누어 패턴을 분류하고 있다. 인프라 컨테이너 애플리케이션을 분리하여 여러개의 작은 서비스를 배포해야하는 마이크로서비스 특성에 맞게, 컨테이너 환경에 사용하여 인프라를 구성하는 것이 좋다. (책에서는 가장 많이 쓰이는 도커를 예시로 들고 있다.) 컨테이너 오케스트레이션 여러개의 컨테이너들을 보다 손쉽게 관리하기 위해 컨테이너..

CQRS (Command Query Responsibility Segregation) 흔히 CRUD (생성, 조회, 업데이트, 삭제) 라고 불리우는 기본적인 4가지 기능들을 상태 변경 명령(CUD), 조회 쿼리(R) 이 두 가지로 나누어 관리하는 방법이다. 명령 모델 (CUD) 와 조회 모델 (R) 을 각각 설계한다. 탄생 배경 기존의 CRUD 아키텍처는 데이터베이스에 쿼리를 하고 업데이트를 하는데에 동일한 Domain Model을 사용합니다. 예를들어 주문 시스템의 Domain Model 은 주문(order)입니다. 주문을 할때에는 배송정보도 필요하고, 상품정보도 필요하고, 추천상품 정보, 고객정보 등 다양한 정보들이 필요합니다. 최초 설계에는 주문만 처리하려고 만들었지만, 유지보수 및 신규 서비스가 ..

2장 MSA의 이해 MSA에서 지켜져야할 특성에 맞게 MSA아키텍처를 효율적이고 올바르게 구성할 수 있는 방법들을 알아본다. 2.1 리액티브 선언: 현대 애플리케이션이 갖춰야 할 바람직한 속성들 리액티브 시스템에 대해서는 여기를 참고. 책에서는 리액티브 시스템에서는 아키텍처 유연성을 갖추는 것이 필수적인 요소라고 말하고 있고 메세지 기반으로 동작하는 방식이 아키텍처 유연성을 충족시켜준다고 한다. 아키텍처 유연성 : 시스템을 구성하는 구성요소 간의 관계들이 느슨하게 맺어져 있어 언제든지 대체되거나 추가 확장될 수 있는 특성. 어떻게 해야 아키텍처가 유연성을 지킬 수 있을까? 느슨한 결합의 아키텍처를 통해 아키텍처 유연성을 만족시킬 수 있다. 2.2 강 결합에서 느슨한 결합의 아키텍처로의 변화 예전에 만들어..

1장 아마존 비지니스 민첩성의 비밀 1.1. 성공한 인터넷 기업들과 비지니스 민첩성 성공한 기업들은 자신들의 “비지니스 민첩성”을 기업 성공의 가장 큰 요인으로 꼽는다. 비지니스 민첩성이란 어떤 것이고, 어떻게 실현할 수 있을까? 비지니스 민첩성 책에서 말하는 비지니스 민첩성은 “민첩성”이라는 단어 그대로, 빠르게 대응하는 것을 의미한다. 예시로, 아마존에서는 초 당 약 1.5번의 배포가 발생한다고 한다. 이 말은, 0.66초에 1번씩 비지니스 개선이 발생한다는 것이다. 아주 빠르게 문제점을 개선하고, 기능을 보완하고, 고객에게 휼륭한 서비스를 제공하게 되는 것이다. 비지니스 민첩성을 위해서는 중요한 3가지 요소가 있다고 말한다. 프로세스 점진 반복적인 개발 프로세스가 필요. 아키텍쳐 유연하고 자동화된 ..

Reactive System 리액티브 시스템 reactive system ⇒ 반응형 시스템. 확장성이 뛰어나고 반응성이 빠른 시스템을 구축하는 데 중점을 둔 소프트웨어 아키텍처이다. 리액티브 시스템의 설계원칙은 리액티브 선언문에 잘 기록되어있다. 우리는 시스템 아키텍처에 대한 일관성 있는 접근이 필요하며, 필요한 모든 측면은 이미 개별적으로 인식되고 있다고 생각합니다. 즉, 응답이 잘 되고, 탄력적이며 유연하고 메시지 기반으로 동작하는 시스템 입니다. 우리는 이것을 리액티브 시스템(Reactive Systems)라고 부릅니다. 리액티브 시스템으로 구축된 시스템은 보다 유연하고, 느슨한 결합을 갖고, 확장성 이 있습니다. 이로 인해 개발이 더 쉬워지고 변경 사항을 적용하기 쉬워집니다. 이 시스템은 장애 에..