DDD-Lite@Spring

https://www.youtube.com/watch?v=TdyOH1xZpT8 

 

📑 복잡성

기술은 빠르게 발전하는데 개발자는 왜 계속 고통받는가

• 왜 우리 프로젝트는 가면 갈수록 더 힘든가
• 왜 유지 보수 비용은 끊임없이 증가하는가
• 진짜 중요한게 대체 무엇인가

No Sliver Bullet. 은탄환은 없다. 어디에서 먹히는 치트키 아키텍처는 없다.

복잡도를 관리하지 못하면 소프트웨어는 위기가 찾아온다. ➡ 대규모 개편이 필요하다.(빅뱅)

빠르고 간단하게 구축하다보니, 서비스가 커지면 주기적으로 프로젝트를 엎고 다시 시작해야한다.

물론 개선을 포기하고, 현재 상태를 유지하는 방법도 있다. 하지만 변화에 적응하지 못하면 비즈니스는 도태된다.

 

 

📑 DDD (Domain Driven Architecture)

큰 프로젝트의 핵심을 뽑아내서 세부 도메인으로 분리하자.

• 핵심 도메인: 비즈니스의 핵심이 되고, 가장 어렵고 복잡한 곳(쇼핑몰 ➡ 결제, 쇼핑 ) 
• 지원 도메인: 핵심 도메인을 도와주는 기능. 부가서비스 (쇼핑몰 ➡ 제품 조회, 배송 조회)
• 일반 도메인: 대부분의 비즈니스에서 필요한 기능 (계정, 이메일... 상용서비스로 대체 가능)

DDD는 여기에서 '핵심' 도메인을 설계하는 방법이다.

 

💭 요구사항을 통해 구축하며 배워보자.

dooray 위키의 간략화 버전

Dooray! - 올인원 협업툴과 전자결재 Dooray!

테넌트(tenant) = 거주자, 입주자

이 중 핵심도메인 Wiki에 대해 파고들어보자.

📑 Entity 설계

엔티티? - 식별(ID)할 수 있고, 생명주기가 있다.

도메인이 풍부해지려면 고수준의 행위가 도메인을 표현할 수 있어야한다.

속성은 행위가 필요할 때 정의한다. 구체적인 사항을 먼저 구현하지 마라. DB 테이블을 먼저 만들어놓고 따라서 만들지마라 (단순 DAO 사용, 빈약한 도메인 모델)

이렇게 행위를 먼저 정의해야한다. create() 행위 지정

 이후 create() 라는 행위에 맞춰 DB를 설계한다.

---

 

 

식별성을 존재하지는 않지만, 도메인의 특정 영역을 추상화 시키는 데이터 : 값 객체

값 객체(content)에 행위를 추가시킬 수 있다. 좋은 패턴

값 객체를 적용할 수 있는 냄새 : prefix가 같은 것

값 객체를 만들어 놓고, 또 조합할 수 도 있다. (값 객체안에 엔티티가 있어도 된다)

---

Aggregate : 도메인의 불변식(데이터 일관성)을 나타내기위해 사용. 데이터 변경(트랜잭션)의 단위

 

초기설계는 무지성으로 만듦. 페이지니까 PageUser랑 같이 묶으면 되겠지?

➡ 하지만 알고보면 PageFile은 유즈케이스가 다름. 페이지를 안거치고 다운로드할 수도 있음 트랜잭션 범위가 다름 

참고로 AggregateRoot는 스테레오 타입. 해당 도메인을 사용하는 통로임

 

참고로 @Version은 낙관적 오프라인 Lock을 JPA에서 제공해주는 것

 

📑 위키 명세가 추가되었다. (요구사항 추가)

도메인 모델에 행위 changeContent를 추가한다.

하지만 보통 비즈니스 핵심 도메인은 이렇게 간단하지 않다. 파고들면 아래와 같다.

요구사항을 조금 더 상세화 하면 이렇게 된다.

어떤 도메인이 요구사항을 처리해야 하는가

페이지가 변경되는 사건(Event)

도메인을 구독하는 책임은 App Service가 가진다.

 

📑 도메인 이벤트를 어떻게 구현하죠

Spring-Data로 하면 간단하게 가능하지만, '트리거'가 있어야 한다. ( 업데이트 이후 Repository.save() 필수 )

스프링 도메인 이벤트 처리 공식문서

최범균 - 도메인 이벤트 처리

 

📑 DDD를 통한 다이어트

앱 로직과 도메인을 분리하라.

행위만 가지고 있는 도메인 서비스를 만들자.

일반적인 트랜잭션 스크립트 코드. 데이터 중심의 코드

도메인 드리븐 코드. 추상화된 패턴 (Facade)

서비스는 뭐다?

속성없이 행위만 있는 곳.

단순한 DAO처럼 get, set만 있던게 행위를 가지며 풍부해졌음.

이벤트 드리븐(발행-구독)모델의 가장 큰 단점은 실행순서가 보장되지 않는다는 것.

누가 호출했는지 추적이 어렵다는 것이다. 그래서 아래와 같이 docs를 달아주는게 좋다.

 

참고로 Spring의 @Repository는 DDD 용도로 만든게 맞다. 실제 Docs에 그렇게 쓰여있었는데

이후 DDD말고 그냥 영속성 영역으로 사용하는 곳도 있으니 약간 설명이 느슨하게 바뀌었다고 한다.

 

JpaRepository와 모양이 비슷하다면 그냥 쓰는게 좋지만

Repository 메서드가 몇개없다면..굳이 스프링에 의존할 필요 있을까.

그냥 순수자바코드로 짜는 것도 고려해보는게 좋다.

---

💭 아키텍처와 모듈

Layerd Architecture는 치명적인 단점이 존재한다.

Hexagonal Architecture를 추천.

 

어댑터는 바인딩 통로

Primary Adapter 는 요청-응답에 대한 어댑터 (Rest Api, batch 등)

Secondary Adapter는 기술적 처리에 대한 통로 (다른 인프라 호출, 영속화DB, Redis캐싱, 메시징 등)

Domain은 도메인 모델

Application은 서비스

Primary 어댑터는 요청-응답 통로 (Rest API, batch등) / Secondary는 기술적 인프라 어댑터 (다른 인프라 호출)

* PageRepository도 기술적 구현이 있기 때문에 도메인 로직임.

Layerd Architecture는 치명적인 단점이 존재한다.

도메인이 인프라에 의존하는 구조이기 때문. 즉 도메인적 관심사와 기술적 관심사가 섞인다.

= 복잡성이 엮어버린다. 도메인과 기술적 관심사, 서비스(앱) 관심사를 완전히 분리해야한다.

DIP를 통해 도메인 모델을 순수하게 유지시키자.

 

어댑터쪽만 살펴본다면 아래와 같다.

참고로 Spring Configuration도 기술으로 볼 수있어서, 어댑터쪽에 두는걸 추천하긴하지만..뭐 기존처럼 최상위 루트에 두고 사용해도 상관은없다.

들어오는 통로 = 프라이머리 어댑터

rabbitMq는 프라이머리, 세컨더리 둘 다 포함된다. (이벤트를 받아도 줘야하니까)

 

레이어드 아키텍쳐는 에릭 에반스 시절의 유물이다.

헥사곤으로 가십쇼..ㅋㅋ

 

 

도메인이 먼저다.

개발자가 욕심히 많다보니 기술부터 정해놓고 도메인을 맞추는경우가많다.

물론 트레이드 오프가 있다.

DDD는 복잡도가 일정하게 유지된다. 그러나 학습곡선이 있다.

골든 크로스 (어플리케이션의 위기)를 맛보았다면 DDD가 왜 필요한지 느낄 것이고, 그게 아니라면 꼭 필요하진 않다.

그러니 어플리케이션의 '핵심' 부분만 DDD를 적용하는 것도 나쁘지 않다.

DDD Lite는 작은 스탭이 큰 변화를 가져올 것이다.