Blog

Spring의 전통적인 Service 계층과 CQRS, Mediator를 같은 선택지처럼 비교할 때 생기는 오해를 바로잡고, 각각의 책임과 도입 기준을 코드로 정리했습니다.

주차타워, 셔틀, 슬롯 같은 설비 도메인을 모델링하면서 Aggregate Root를 먼저 정하려다 헤맸던 경험을 정리했습니다. 설비 마스터 정의와 Aggregate 설계는 다른 작업이라는 것, 그리고 판단 기준과 흔한 오해 네 가지에 대하여.

UseCase 내부 단계를 인터페이스로 뽑고 싶은 유혹은 대체로 과잉 추상화입니다. 인터페이스가 필요한 경우와 과한 경우를 나누고, '필요해질 때 승격시키기'라는 실용적인 기준을 정리했습니다.

더 이상 쪼갤 수 없는 최소 단위의 유스케이스, Leaf UseCase 개념을 정리했습니다. 반복적으로 필요해지는 Leaf가 Application Service로, 필요하면 인터페이스로 승격되는 타이밍이 됩니다.

Application Service라는 용어가 CQRS, Clean Architecture, DDD, Hexagonal Architecture에서 각각 어떻게 쓰이는지 정리했습니다. 네 관점을 나란히 놓고 보면 하나의 판단 기준으로 수렴합니다.

CQRS 패턴의 Command/Query Handler와 전통적인 Application Service 사이에서 겪은 혼란을 정리했습니다. 두 패러다임을 조화롭게 융합하는 기준에 대하여.