태그: DDD
이 태그가 달린 모든 글 "DDD".
-
[DDD Intro #30] 내가 이해한 DDD: 좋은 설계는 좋은 질문에서 시작된다
DDD를 처음 접하면 용어가 먼저 보인다. Entity, Value Object, Aggregate, Repository, Domain Service, Domain Event, Bounded Context, Context Map. 여기에 CQRS, Event Sourcing, Hexagonal Architecture, Microservice까지 이어지면 DDD는 거대한 기술 체계처럼 느껴진다.
-
[DDD Intro #29] DDD 도입 체크리스트
DDD는 강력한 접근이지만 모든 문제에 필요한 것은 아니다. 복잡한 도메인에는 큰 도움이 되지만, 단순한 CRUD 시스템에 과하게 적용하면 오히려 비용만 늘어날 수 있다.
-
[DDD Intro #28] 모듈러 모놀리스: 마이크로서비스 전에 생각할 것
시스템이 커지면 서비스를 나누고 싶어진다. 주문, 결제, 회원, 알림, 정산을 각각 독립 서비스로 만들면 더 깔끔해질 것 같다. 각 팀이 자신의 서비스를 소유하고, 독립적으로 배포하고, 장애도 격리할 수 있을 것처럼 보인다.
-
[DDD Intro #27] 레거시 시스템에 DDD 적용하기
DDD를 공부하다 보면 깨끗한 예제를 많이 보게 된다. 도메인 객체는 선명하고, 계층은 분리되어 있으며, Aggregate 경계도 잘 잡혀 있다. 하지만 현실의 시스템은 그렇지 않은 경우가 많다.
-
[DDD Intro #26] 테스트로 도메인 모델 설명하기
테스트는 보통 버그를 막기 위한 도구로 여겨진다. 물론 맞는 말이다. 테스트는 코드가 기대한 대로 동작하는지 확인하고, 변경이 기존 기능을 깨뜨리지 않도록 돕는다.
-
[DDD Intro #25] Microservice와 DDD: Bounded Context는 서비스인가
DDD를 이야기하면 마이크로서비스가 함께 등장하는 경우가 많다. Bounded Context를 나누고, 각 컨텍스트를 서비스로 만들고, 독립 배포와 독립 데이터베이스를 갖추는 그림은 매력적이다.
-
[DDD Intro #24] Event Sourcing은 DDD의 필수가 아니다
Domain Event를 배우고 나면 자연스럽게 Event Sourcing을 만나게 된다. 도메인에서 일어난 일을 이벤트로 표현한다면, 아예 상태가 아니라 이벤트를 저장하는 것이 더 좋은 것처럼 보인다.
-
[DDD Intro #23] CQRS: 읽기 모델과 쓰기 모델을 분리해야 할 때
DDD를 공부하다 보면 CQRS라는 단어를 자주 만나게 된다. 그래서 DDD를 제대로 하려면 CQRS를 해야 하고, CQRS를 하려면 이벤트 소싱까지 해야 한다고 생각하기 쉽다.