ㄷㄷㄷ: Domain Driven Design과 적용 사례공유

https://www.youtube.com/watch?v=4QHvTeeTsj0 

 

 

카카오엔터테인먼트 이한승(셜록)님의 발표를 듣고 요약해보고자 합니다.

 

 

파트너 사이트란?

Contents Provider 들을 위한 사이트

 

Legacy Server

• Monolithic
• 기술 부채
• 유지보수의 어려움
• 기능의 고착화

 

Domain Driven Design이란?

• 데이터에 집중하지 않고 도메인의 모델과 로직에 집중
• 유비쿼터스 언어(업무 용어 통일) 사용
• Software Entity와 Domain 간 개념의 일치
  • 도메인 모델과 코드까지 함께 움직이는것을 지향

 

Why DDD?

TDD, BDD, DDD를 설명하는 다이어그램

• 파트너 사이트는 이미 큰 틀과 검증된 레거지 플로우가 존재
• 이에 따라 필요한 부분을 조금씩 구별하여 개선하고 점진적인 향상을 선택

 

사람이 없어요, 시간이 없어요

 

DDD를 위한 선행 작업

• Bounded Context

Bounded Context

경계를 나누고 MSA 서비스로 나누게 됨

각 도메인을 철저하게 분리하고 필요시에 API로 통신하도록 함

 

• Context Map

Context Map

upstream과 downstream으로 나누어 Map을 그립니다.

Publisher(=Upstream)

Subscriber(=Downstream)

 

 

• Aggregate

Aggregate

서비스가 가지고 있는 객체를 그대로 사용하는것은 의미가 없기 때문에 서비스의 도메인 객체 집합을 설계하게 되고 이를 Aggregate라고 합니다.

 

비디오 Product의 aggregate예시이며 데이터의 변경단위입니다.

라이프사이크가 비슷한 객체들이 모여 있으며 root entity를 통해서만 CRUD가 이루어지고, 하위의 entity에 영향을 미치게 됩니다.

이제 객체들의 상호작용을 넓은 관점에서 바라볼 수 있게 됩니다.

 

bounded context에는 여러 개의 aggregate가 존재할 수 있습니다.

 

 

Architecture

• Layered Architecture
  • User Interface
  • Application
  • Domain
  • Infrastructure
• Clean Architecture
  • External Interface (DB, UI)
  • Interface Adapter
  • Use Case
  • Entity(Domain)
• Hexagonal Architecture
  • Adapter & port
  • use case
  • entity

 

Hexagonal Architecture 선택

 

파트너 사이트의 Hexagonal Architecture

파트너 사이트의 Hexagonal Architecture

• 사용자의 판매 요청이 Controller에서 Service 포트로 인입됩니다.
• application domain에서 처리가 완료됩니다.
• Repository에서 persistence Adapter를 통해 DB에 데이터 요청을 처리합니다.
• 처리에 대한 항목을 요약하며 Notification 알림을 위한 메시지를 발행합니다.

 

코드 예시

Product 도메인에는 작품에 대한 판매정보, 메타정보, 콘텐츠 파일 정보가 존재합니다.

그리고 판매가 시작하면 유효성검사와 판매날짜 시작에 대한 로직이 들어갑니다.

 

Controller에서는 productId를 받고 usecase를 호출합니다.

 

ProductUseCase는 SaleService가 구현하고 있습니다.

 

작품을 판매하기 위해 조회하기 위해 loadProductPort

저장하기 위한 saveProductPort

이벤트를 발행하기 위한 EventPublishPort

 

CQRS 패턴을 위해 이렇게 분리하고 조회를 event driven으로도 바꾸기 위해서입니다.

 

 

 

 

LoadProductPort와 SaveProductPort는 ProductPersistenceAdater에서 구현하고 있습니다.

이때 ProductJpaEntity를 ProductEntity로 바꾸어주는 mapper를 구현해주어야 합니다.

 

There is No Silver Bullet

단점들

• MSA에서 오는 단점들
  • 복잡해진 개발 난이도 및 숙련도
  • 트랜잭션에 대한 관리와 통합 테스트의 힘듦
• 생각보다 많은 코드양

장점들

• 각 도메인에 대한 높은 이해도가 필요보편적인 언어 사용에 따른 빠른 커뮤니케이션
• 도메인 간 관계가 복잡한 경우 큰 틀에서 정리가 가능
• 도메인의 분리에 따른 유지보수에 대한 편의성
• 새로운 기능 및 요구사항에 대한 유연성
• 캡슐화가 잘 적용됨
• Loose coupling, High cohesion
• Domain Logic의 분리로 Business Logic에 집중
• 코드 가독성 향상

 

 

 

 

 

 

 

참고 자료

https://happycloud-lee.tistory.com/94