글
작성한 모든 글입니다.
-
[DDD Intro #22] 트랜잭션과 일관성: 무엇을 한 번에 지켜야 하는가
소프트웨어에서 일관성은 중요하다. 주문이 생성되었는데 결제 정보가 없거나, 구독이 갱신되었는데 이용 권한이 부여되지 않거나, 환불이 완료되었는데 정산 금액이 그대로라면 문제가 된다.
-
[DDD Intro #21] ORM과 DDD: JPA Entity는 도메인 모델인가
Java와 Spring 환경에서 DDD를 이야기하면 거의 반드시 JPA 이야기를 만나게 된다. Entity라는 단어가 겹치기 때문이다. JPA에도 Entity가 있고, DDD에도 Entity가 있다. 그래서 많은 팀이 자연스럽게 JPA Entity를 도메인 모델로 사용한다.
-
[DDD Intro #20] Hexagonal Architecture: 도메인을 중심에 두는 구조
계층형 아키텍처는 도메인 모델을 보호하기 위한 중요한 출발점이다. 하지만 실제 코드에서는 계층이 한 방향으로만 흐르는 것처럼 보이면서도, 도메인이 여전히 프레임워크나 데이터베이스에 강하게 묶이는 경우가 많다.
-
[DDD Intro #19] Layered Architecture: 도메인 계층을 보호하기
DDD를 구현하려고 하면 곧 아키텍처 이야기를 만나게 된다. Presentation Layer, Application Layer, Domain Layer, Infrastructure Layer 같은 이름이 등장한다. 패키지를 나누고, 의존성 방향을 정하고, 각 계층의 책임을 구분한다.
-
[DDD Intro #18] Specification과 Policy: 조건과 정책을 모델링하기
도메인 로직은 처음에는 작은 조건문으로 시작한다. 특정 상태이면 처리하지 않고, 특정 날짜가 지나면 만료시키고, 특정 요금제이면 할인하지 않는다. 처음에는 if 몇 개면 충분하다.
-
[DDD Intro #17] Factory: 생성에도 도메인 지식이 있다
객체 생성은 종종 단순한 기술 문제처럼 여겨진다. 생성자를 호출하고, 필요한 값을 넣고, 필드를 채우면 끝이라고 생각하기 쉽다. 하지만 도메인 모델에서는 생성도 중요한 행위일 수 있다.
-
[DDD Intro #16] Domain Service: 객체에 억지로 넣기 어려운 도메인 로직
DDD를 공부하면 “도메인 로직은 도메인 객체 안에 있어야 한다”는 말을 자주 듣는다. 이 말은 중요하다. 도메인 규칙이 Application Service나 Controller에 흩어지면 모델은 빈약해진다.
-
[DDD Intro #15] Application Service: 유스케이스를 조율하는 계층
DDD를 적용할 때 가장 혼란스러운 이름 중 하나가 Service다. Application Service, Domain Service, Infrastructure Service가 모두 Service라는 이름을 갖는다. 그래서 시간이 지나면 모든 로직이 SomethingService에 모인다.