I am an amazing person.

3 minute read

디디디 원해!

ddd1

  • 회사에서 새로운 기능을 만들게 되면 항상 데이터 설계를 먼저하고 그에 맞춰 로직을 설계하게 된다. 시간이 지난 후 기능을 추가할때면 데이터에 묶여서 원하는 기능을 다 만들지 못하게 되는 문제가 발생하게 될때가 많다.
  • 그러다보니 작업을 하면서 이런 문제를 어떻게하면 벗어날 수 있을까라는 고민이 마음 속 한 구석에 계속 있었다. DDD 를 알게되고 도메인을 먼저 정의하고 설계하면 이 문제에서 조금 벗어날 수 있을 거 같았다.
  • 또한 회사에서도 일을 하다보면 작업 관련자들끼리 대화를 하면서도 대화가 안될때가 많다. 그 중 대부분의 이유는 같은 언어(용어)를 쓰더라도 다른 의미로 사용할때가 많아서다.

  • 단적인 예로 한번은 회사에서 B2B 티켓 이라는 단어를 개발자들은 비즈니스 회원한테만 판매하는 티켓으로 받아들이고 사업부에서는 일반 회원에 판매하는데 티켓명이 B2B 티켓이고 보이는 것만 B2B 용으로 보이는 게 하는 것이였다. 회의를 하면 할수록 서로 이해를 하지 못했고 긴 시간이 지나고 나서야 서로 다른 이야기를 했다는 것을 깨달은 적이 있다.

    ddd2

  • 이런 경험들이 쌓이면 커뮤니케이션을 할때 언어(용어) 통일이 얼마나 중요한 지 알 수 있다. 도메인 주도 설계를 하면 서로 같은 단어를 다르게 쓰지 않기 위한 “약속”을 한다. 그러면 커뮤니케이션 미스를 줄일 수 있고, 위와 같은 단어를 쓸때 다른 작업자가 잘못 생각할 수 있다는 걸 자각할 수 있을 거 같았다.

ddd3

  • 도메인을 설계할때 하는 이벤트 스토밍은 개발하는 서비스에 대해서 개발자가 혼자 설계하는 것이 아니라 관련된 작업자들 모두가 해당 서비스를 같이 정의한 후 개발이 들어가서 서로 이해가 좀 더 명확한 상태에서 진행한다는 점에서 꼭 해보고 싶다.

그래서 DDD 그게 뭐야?

DDD (Domain Driven Design)

  • 해당 도메인과 일치하도록 소프트웨어를 모델링하는 데 중점을 둔 소프트웨어 설계 접근 방식
  • 여기에서 말하는 도메인
    • 비즈니스 도메인 : 유사한 업무의 집합, 회사가 제공하는 서비스
    • 하위 도메인 : 비즈니스 활동의 세분화된 영역, 제공하는 서비스 단위
  • 소프트웨어 코드의 구조와 언어(클래스 이름, 메소드, 변수)를 비즈니스 도메인의 용어와 일치시켜 나가는 설계방식
  • 소프트웨어의 연관된 부분들을 연결하여 계속해서 진화하는 새로운 모델을 만들어 나가 복잡한 어플리케이션을 만들기 쉽게 해준다.

도메인 지식

  • 도메인 전문가가 문제를 생각하는 방식
  • 기존 구현 과정
    • 분석(분석모델) → 설계(설계모델) - → 구현(코드)
  • 도메인 주도 설계
    • 설계 (도메인 모델) → 구현(도메인모델을 포함한 코드)

유비쿼터스 언어

ddd4

  • 프로젝트 구성원 모두에게 공유된 언어
  • 도메인 지식을 변환하는 대신 도메인을 설명하기 위한 단일화된 체계
  • 도메인의 의도를 정확히 반영하고 핵심 개념이 잘 표현될 수 있도록 정의해야함
  • 정확하고 일관성이 있어야하며 모호한 용어는 안됨
  • 지속적으로 발견하고 발전시킴

도메인 모델

ddd5

  • 특정 도메인을 개념적으로 표현한 것으로 도메인의 핵심 규칙을 구현한다.
  • 모델은 본질적으로 추상화의 결과이며, 실 세계의 복잡성을 관리한다.
  • 도메인 모델링 : 유비쿼터스 언어로 사실상 비즈니스 도메인 모델을 구축하는 것
  • 명사와 행위를 파악

바운디드 컨텍스트

  • 모델의 경계
  • 유비쿼터스 일관성이 유지되는 경계
  • 유비쿼터스 언어의 용어, 원칙, 비지니스 규칙은 해당 바운디드 컨텍스트 내에서만 일관성이 있다.

바운디드 컨텍스트 vs 하위도메인

  • 하위도메인 → 비지니스 전략에 의해 정의됨
  • 바운디드 컨텍스트 → 소프트웨어 엔지니어에 의해 설계됨
  • 하위 도메인은 발견되고 바운디드 컨텍스트는 설계한다는 점

컨텍스트 매핑

  • 컨텍스트 간 연관관계 표현으로 바운디드 컨텍스트를 다른 바운디드 컨텍스트와 데이터를 주고 받는 것.
  • 유형
    • 협력형 패턴
      • 파트너십
      • 공유 영역
    • 공급자, 소비자 패턴
      • Supplier - customer : upstream, downstream
      • Conformist (순응주의자) - 힘의 균형은 상류에 존재
      • ACL (충돌방지계층) - 하류가 이에 순응하지 않은 경우
      • OHS(오픈 호스트 서비스) - 힘이 사용자 측에 있는 경우, 제공자는 사용자를 보호하고 가능한 최고의 서비스를 제공함, 여러 사용자에 따른 버전 관리 가능
      • PL(공개 프로토콜, 공표된 언어) - 명세

이벤트 스토밍

ddd6 ddd7

  • 도메인 전문가와 개발자가 같이 참여하여 어떻게 전략적으로 설계를 효율적으로 할 것인가 같이 고민하는 것
  • 서비스에 필요한 모든 사람들이 다 같이 모여서 진행한다.
  • 개발요소가 아닌 이벤트와 비즈니스 프로세스에 집중한다.
  • 팀 구성원 전체가 서비스 이해도를 증가할 수 있고, 도메인 전문가도 이해의 폭을 다시 넓히고 새로운 통찰력을 얻을 수 잇다.
  • Domain Event
    • 시스템에 발생하는 중요한 이벤트
    • 데이터가 아닌 비즈니스 프로세스 에 집중
    • 과거형 동사 로 표현
  • Hot Spot
    • 질문, 가정, 경고, 의견 수렴이 필요한 내용
    • 병목 구간, 자동화 필요한 수작업, 도메인 지식이 없는 경우
    • 완전히 정의되니 않은 영역, 해결해야하는 문제
    • 필요한 곳 어디에나 부착 가능
  • Command
    • 이벤트를 트리거 하는 명령
    • 현재 동사 로 표현
  • Actor
    • Command 를 동작하게 하는 사용자/역할
    • 사람 이나 역할의 이름 을 명사(단어) 로 표현
  • Policy
    • 다른 바운디드 컨텍스트에 영향을 주는 이벤트
    • Domain Event 가 발생하면 파생되는 동작
    • 만약 ~ 하면 ~ 한다.
  • External System
    • 연계가 필요한 외부 시스템 또는 프로세스
    • 명사(단어) 로 표현
  • Aggregate
    • Domain Event 와 Command 에 의해 관리되는 데이터
    • Domain Event 와 Command 를 표현하는 키워드
    • 명사(단어) 로 표현

이벤트 스토밍 결과를 헥사고날 아키텍처와 매핑

ddd8

[참고] https://vaadin.com/blog/ddd-part-3-domain-driven-design-and-the-hexagonal-architecture

https://ko.wikipedia.org/wiki/도메인_주도_설계

https://blog.naver.com/PostView.naver?blogId=seek316&logNo=222710251462

https://devlos.tistory.com/category/MSA 설계 %26 도메인주도 설계

https://engineering-skcc.github.io/msa/DDD-StrategicDesign/

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

https://incheol-jung.gitbook.io/docs/q-and-a/architecture/ddd

https://www.linkedin.com/pulse/why-bounded-context-crucial-micro-services-manish-mehndiratta-togaf-

You may also enjoy