Blog

Big-O를 단순히 외우는 대신 데이터가 증가할 때 연산량이 어떻게 변하는지 정리했습니다. O(1)부터 O(N²)까지의 차이와 반복문, 이진 탐색, HashMap을 이용한 개선 사례를 살펴봅니다.

EF Core를 쓸 때 Repository 패턴을 끼워야 하는지, DbContext를 그대로 써도 되는지 정리했습니다. 판단 기준은 결국 도메인 규칙을 얼마나 강하게 지켜야 하는가였고, 그 판단이 DbSet 등록 범위와 IEntityTypeConfiguration을 통해 EF Core 위에서 실제로 Aggregate 경계를 지키는 코드로 어떻게 이어지는지도 함께 정리했습니다.

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 사이에서 겪은 혼란을 정리했습니다. 두 패러다임을 조화롭게 융합하는 기준에 대하여.