파이썬으로 살펴보는 아키텍처 패턴

이벤트 드리븐 아키텍처 잘못된 접근법 1️⃣ - 시스템을 명사로 바라보기 >"이 시스템의 '물건'마다 연관된 서비스가 있고 서비스는 HTTP API를 노출한다."(p.231) `유저, 매니저, 매치, 주문, 대관` 등과 같이 명사로 표현해왔다. 이는 코드 복잡도가 증가할 수 있는 구조다. happy path `유저 매치 지원 -> 매니저 통보`...

커맨드 핸들러(Command handler)

상속보단 조립

애그리게이트

UoW(Unit of Work)

1️⃣ 아키텍처 리팩토링 지난 시간까지 Domain 계층과 Repository 계층에 대해 배웠다. 실세계의 웹 애플리케이션에서의 아키텍처는 어떻게 달라야 할까? 1) 우선 API 방식으로 프로덕트가 움직인다. 장고, 플라스크 등의 API 계층이 필요하다. 2

1️⃣ 쓰기 위해 존재하는 도메인 모델 지금까진 도메인 규칙을 반영하는 소프트웨어에 초점을 맞췄다. "현재 사용 가능한 재고보다 더 많은 재고를 할당할 수 없다." "각 주문 라인은 한 배치에만 할당된다." 위의 도메인 규칙을 검증하는 유닛 테스트는 다음과 같다. 프로덕션 환경에서 경합조건으로 인한 문제를 해결하기 위해 `작업의 일관성`이 보장돼야 ...

DI

1️⃣ 데이터 모델링에서 벗어나기 > 대부분 개발자는 도메인 모델을 본 적이 없으며 데이터 모델만 봤을 것이다 -Cyrille Martraire, DDD EU 2017 새로운 시스템 도입이 생기면 DB모델링에 바로 착수해왔다. 하지만 여기서부터 모든 것이 잘못되는

Recap 서비스 계층(=애플리케이션 서비스) : DB에서 데이터를 얻어 도메인 모델을 업데이트하고 영속화하는 모든 연산을 오케스트레이션한다. 단점 웹 앱인 경우, 컨트롤러/뷰 함수가 이미 있다. 서비스 계층도 추상화를 하나 만든 것에 불과하다. 서비스 계층이 비대

장고와 저장소 패턴은 공존할 수 있는가

장고와 저장소 패턴은 공존할 수 있는가

추상화