Django는 아래와 같은 특성 때문에 클린 아키텍처와 DDD를 적용하기 어렵다. (프레임워크의 의도와 다르게 코드를 작성해야하는 경우가 생긴다.) 액티브 레코드 패턴을 사용하는 Model -> 도메인 모델로만 사용하기 어렵고 DB 테이블 구조와 밀접하게 연관 비즈니스 로직과 엮여있는 View -> 뷰에 비즈니스 로직을 구현하기 쉬운 구조 Django ORM -> 데이터를 가져오고 저장하는 방식이 특정 ORM 코드에 종속됨 차선으로 DDD를 선택적으로 적용한 Layered 아키텍처를 생각한다. MSA로 확장 가능성을 고려해서, …

Read More

패턴 개괄 애플리케이션 패턴(application pattern): 개발자가 맞닥뜨리는 문제를 해결합니다. 분해: 시스템을 여러 서비스로 분해하는 기준을 결정하는 것. 비즈니스 능력 <-> 하위 도메인(DDD) 쿼리: 분산 db에서 쿼리하는 방법 API 조합 <-> CQRS 데이터 일관성: 분산 db 간 일관성 유지하는 방법 참고 - 2PC는 가용성 이슈와 성능 이슈 때문에 제외 테스트 자동화: 가급적 E2E를 피하고, 서비스 별로 분리하여 테스트하는 단순화가 필요 consumer-driven contract test / consumer-side …

Read More

content 데이터 스트림에 영향을 미치는 모든 변경 사항을 observer 들에게 전파하는 프로그래밍 리액티브 매니페스토 반응성(responsive) : 리액티브 시스템은 빠를 뿐 아니라 + 일정하고 예상가능한 반응 시간을 제공한다. 회복성(resilient) : 장애가 발생해도 시스템은 반응해야한다. 여러 컴포넌트의 시간과 공간 분리 (즉, 컴포넌트가 각각 독립적인 생명주기를 갖고 다른 프로세스에서 실행), 작업 위임시 비동기적으로 위임하는 등의 기법이 있다. 탄력성(elastic) : …

Read More

(주로)MSA에서 프로바이더 서비스들이 제공하는 데이터를 조합하여 한번에 제공하는 API 조합기를 두는 패턴 설계 API 조합기로 둘 컴포넌트 선정 클라이언트 간단하지만, 클라이언트가 외부 네트워크에 존재하는 경우 느리다 API 게이트웨이 일반적인 방법으로 API 게이트웨이 패턴이라 불림 스탠드 얼론 서비스 ‘주문 검색 서비스’ 와 같은 서비스를 두어 조합기 역할을 맡기는 방법 효율적인 조합 로직 프로바이더 서비스 순차 호출에 따른 지연 시간을 줄이는 것이 핵심 리액티브 프로그래밍을 권장 refs 마이크로서비스 패턴 links API …

Read More

content 프록시를 사용하여 서비스 간의 통신을 관리하는 인프라 계층. 도커와 쿠버네티스는 수많은 마이크로서비스의 오케스트레이션을 가능하게 하였고, 이들 서비스 간에 흐르는 트래픽을 추적하고 관리하려는 목적으로 서비스 메시를 사용한다. (어플리케이션 레벨이 아니라) 인프라 레벨에서 1) 트래픽 관리 2) observability 3) 보안 강화의 기능을 제공한다. refs 실무자를 위한 서비스 메시 - 지금 서비스 메시가 의미 있는 이유 links

Read More

API Gateway Pattern 을 정확히 이해하자 MSA에 API Gateway Pattern이 필수적임 API Gateway Pattern은 API Gateway Framework와는 무관함 내부 api를 제공(단순 라우팅)할 용도로 API Gateway Framework를 쓰지말자 -> controller와 facade가 없는 프레젠테이션 레이어를 구현하게됨 인가 로직이 비즈니스 레이어(각각의 마이크로서비스)에 들어가야해서 오염됨 로직 구현의 책임을 잘못된 곳에 전가함 클라이언트가 여러 로직을 직접 호출하여 조합하거나 특정 서비스가 자신의 도메인인 것처 …

Read More

Command와 Query를 다른 것으로 보고 명시적으로 분리하는 패턴. OOP 관점에서 Command를 담당하는 객체와, Query를 담당하는 객체의 책임을 분리하는 것으로 이해하면된다. MSA, DDD, 이벤트 소싱 등 다른 기술과 함께 활용되며 다양하게 구현한다. 특히 마이크로 서비스로 분리한 아키텍처에서는 Query가 어려운데, 여러 서비스에 흩어진 데이터를 조회하는 비용이 크기 때문이다. 그래서 Query 효율을 높이는 관점에서 CQRS를 많이 활용한다. refs 마이크로서비스 패턴 links

Read More

동작을 구현한 클래스와 상태를 표현하는 클래스를 분리하여, 비즈니스 로직을 요청 타입에 따라 별도로 구분된 절차적 트랜잭션 스크립트로 작성한 패턴이다. 구현이 쉽고 빠르며, 비교적 단순한 비즈니스 로직에 적합하다. 동작과 상태를 모두 구현하여 책임을 분리한 도메인 모델과는 대비되는 개념이다. 비즈니스 로직이 복잡해지고 여러 클래스가 복잡하게 얽힐수록, OOP적으로 잘 설계된 도메인 모델의 가치는 높아진다. 도메인 모델 패턴에서는 도메인 객체가 비즈니스 로직을 처리하여, 서비스 클래스는 가벼워진다. refs 마이크로서비스 패턴 Django와 Layered …

Read More

2단계 커밋(Two Phase Commit) 으로 분산 트랜잭션 환경에서 트랜잭션을 구현하는 방법이다. 트랜잭션의 커밋을 준비와 실제 동작의 2단계로 나누어, 분산 환경에서 커밋 준비가 완료되면 비로소 실제 커밋을 하는 방식이다. 2PC 에서 원자성은 2개의 되돌릴 수 없는 포인트에 의해 결정되는데, 1) 참여자가 준비 단계에서 커밋 가능하다고 답변하는 시점과 2) 코디네이터(리소스 매니저)가 커밋하는 시점이다. 1)과 2) 가 만족되면 참여자의 커밋이 어떤 사유로 실패하든, 반복적으로 커밋을 시도한다. 트랜잭션에 관여하는 모든 서비스가 정상 동작해야하는 가용성 이슈 …

Read More

content 분산 트랜잭션 환경에서 서비스 간 비동기 메시징을 이용하여 편성한 일련의 로컬 트랜잭션. 각 서비스가 변경분 커밋을 수행하고 완료 메시지를 발행하여 다음 서비스의 트랜잭션을 유도한다. 마찬가지로 각 서비스는 보상 트랜잭션(compensatable transaction)을 통해 문제 발생 시 변경분을 발생 역순으로 undo하도록해 롤백한다. 분상 환경에서 메시징을 이용하는 특성상, saga 그 자체로는 엄격한 Isolation을 제공할 수 없다. 메시지 읽고 처리하는 행위를 격리하기 힘들기에, 메시지 읽는 순서가 바뀐다든지 하는 이슈로 트랜잭션의 결과가 …

Read More

content 트랜잭션의 속성(ACID)을 2개 이상으로 분산된 네트워크에서도 만족시키는 트랜잭션. X/Open DTP(XA) 모델이라는 표준이 있으며, 이는 2단계 커밋(2PC)를 활용하여 각 리소스를 트랜잭션으로 관리한다. 요즘엔 2PC 대신 Saga 패턴을 쓰는 추세이다. refs 분산 트랜잭션 - 위키백과, 우리 모두의 백과사전 X/Open XA - 위키백과, 우리 모두의 백과사전 마이크로서비스 패턴 links Transaction 2PC Saga 패턴

Read More

refs links

Read More