글
작성한 모든 글입니다.
-
[DDD Intro #14] Repository: DAO가 아니라 도메인 컬렉션처럼 다루기
DDD에서 Repository는 자주 오해되는 패턴이다. 많은 코드에서 Repository는 사실상 DAO처럼 사용된다. 데이터베이스에서 데이터를 조회하고, 특정 컬럼을 수정하고, 필요한 쿼리를 실행하는 객체가 Repository라는 이름을 갖는다.
-
[DDD Intro #13] 도메인 객체에 행위를 넣는다는 것
DDD를 적용한다고 말하면서도 실제 코드를 보면 도메인 객체가 거의 아무 일도 하지 않는 경우가 많다. 클래스 이름은 Subscription, Order, Payment처럼 도메인스럽지만, 내부에는 필드와 getter, setter만 있다. 중요한 규칙은 대부분 SubscriptionService, OrderService, PaymentService 같은 서비스 클래스에 들어 있다.
-
[DDD Intro #12] Entity: 식별성과 생명주기를 가진 도메인 객체
Value Object는 값으로 식별된다. 10,000원은 10,000원이고, 같은 시작일과 종료일을 가진 기간은 같은 기간이다. 중요한 것은 그 값 자체다.
-
[DDD Intro #11] Value Object: 원시값이 아니라 도메인 개념으로 표현하기
DDD의 전술적 패턴을 떠올리면 많은 사람이 Entity부터 생각한다. 식별자, 생명주기, 상태 변화가 있는 객체는 분명 중요하다. 하지만 실제 코드에서 도메인 의미를 가장 작고 선명하게 드러내는 출발점은 Value Object일 때가 많다.
-
[DDD Intro #10] Anti-Corruption Layer: 외부 모델로부터 내 모델을 지키기
좋은 도메인 모델을 만드는 일은 어렵다. 도메인 전문가와 대화하고, 유비쿼터스 언어를 다듬고, Bounded Context를 나누고, Aggregate 경계를 고민해야 한다. 그런데 어렵게 만든 모델도 쉽게 망가질 수 있다.
-
[DDD Intro #9] Context Map: 경계는 혼자 존재하지 않는다
Bounded Context를 이해하면 모델을 하나로 합치려는 욕심을 내려놓게 된다. 같은 단어라도 맥락에 따라 다른 의미를 가질 수 있고, 하나의 거대한 모델보다 여러 개의 일관된 모델이 더 나을 수 있다는 사실을 받아들이게 된다.
-
[DDD Intro #8] Core Domain: 모든 곳에 같은 정성을 쏟지 않는다
DDD를 공부하다 보면 좋은 설계를 모든 곳에 적용하고 싶어진다. Entity를 만들고, Value Object를 만들고, Aggregate를 나누고, Repository와 Domain Service를 세운다. 도메인 이벤트도 발행하고, 계층도 깔끔하게 분리한다.
-
[DDD Intro #7] DDD가 실패하는 이유
DDD를 공부하고 나면 설계가 더 좋아질 것처럼 느껴진다. Entity, Value Object, Aggregate, Repository, Domain Event 같은 개념을 익히고 나면 복잡한 비즈니스 로직도 깔끔하게 정리될 것 같다.