스터디 진행 일시
날짜 : 9월 18일 (목요일) 시간 : 오후 7시 ~ 9시 (2시간) 장소 : 강남 (오프라인)


🔧 금주 스터디 일정
  • 아이스 브레이킹
  • DDD, 도메인 주도 개발은 무엇일까?
  • 애자일의 철학


"~ 주도 개발"은 무엇일까?

DDD, TDD (Test-Driven Development) 같은 “주도 개발”은 많이 들어봤는데, 이게 정확하게 무엇일까?

“~주도 개발” 이라는 말은 무엇을 중심(Driver)으로 삼아 개발을 이끌어가느냐를 표현하는 방식이다. 즉, 개발 과정에서 우선순위를 두는 기준이 다르게 두는 것을 말한다.

대표적인 주도 개발 방법론은 TDD(Test), BDD(Behavior), DDD(Domain), FDD(Feature), MDD(Model) 가 있다.


도메인 주도 개발(DDD)가 무엇일까?

DDD(Domain Driven Design)는 비즈니스 도메인을 중심에 두고 진행하는 방법론이다. 기술보다 해결해야 할 비즈니스 문제를 먼저 보고 정의하고, 이를 코드와 아키텍처에 반영한다.


도메인 주도 개발이 왜 나왔을까 ?

기존 개발 방식은 주로 절차지향이나 객체지향이었는데, 서비스가 커질수록 한계가 드러나기 시작했다.

  • 코드가 복잡해지고 비즈니스 로직이 뒤엉킴
  • 팀 내 커뮤니케이션 단절
  • 변경 사항 발생 시 영향 범위를 예측하기 어려움

도메인 주도 개발(DDD) 은 이런 문제를 해결하기 위해, 도메인 지식을 코드에 직접 반영하고, 비즈니스 전문가와 개발자가 공통 언어(유비쿼터스 언어)를 사용하는 것을 강조한다.

참고로 DDD가 도메인을 중심으로 시스템을 설계하는 방법론이라면, MSA는 그 설계 결과를 실제 아키텍처로 구현한 형태다. 그래서 DDD가 반드시 MSA로 이어지는 건 아니지만, DDD를 잘 해두면 MSA로 전환하기 수월하다.


유비쿼터스 언어(Ubiquitous Language)

유비쿼터스 언어

DDD의 핵심 개념 중 하나는 유비쿼터스 언어이다.

  • 도메인 전문가(기획자, 현업)와 개발자가 공통으로 쓰는 언어를 말한다.
  • 비즈니스 용어를 그대로 코드, 모델, 문서에 녹여내서 커뮤니케이션 격차를 줄이는 것이 목표이다.


왜 중요할까 ?

비즈니스 담당자가 “청구서”라고 부르는데 코드에서는 “InvoiceEntity” 대신 “BillObject” 같은 이름을 쓰면 혼란 발생할 수 있다. 특히나 요구사항이 바뀔 때 대화 내용과 코드 사이에 불일치 발생으로 인해 유지보수의 어려움이 발생할 수 있다.

예를 들어 보험 도메인을 코드로 녹여낸다면 아래와 같다.

  • 현업 : 보험을 청구하고 심사하고 지급한다.
  • 코드로 그대로 반영하면 아래와 같다.


class Claim {  // 청구
    void submit();   // 접수
    void review();   // 심사
    void pay();      // 지급
}


애그리거트(Aggregate)와 루트(Root)
  • 애그리거트가 무엇일까 ?
    • 비즈니스적으로 강하게 연관된 객체(엔티티, 값 객체)의 묶음을 말한다.
    • 외부에서는 애그리거트 전체를 직접 접근하지 않고 루트(Root)를 통해서만 접근한다.


  • 애그리거트 루트는 무엇일까 ?
    • 애그리거트 내부에서 외부외 연결되는 유일한 진입점이다.
    • 루트를 통해서만 다른 엔티티/값 객체에 접근하거나 수정 가능하다.
    • 데이터 무결성과 도메인 규칙을 보장한다.


예를 들면 주문(Order) 도메인이라면 아래와 같다.

Order (주문)  ← Aggregate Root
 ├── OrderItem (주문 항목)
 ├── Payment (결제 내역)
 └── ShippingInfo (배송 정보)
  • Order가 애그리거트 루트
  • 외부에서는 OrderItem 이나 Payment에 직접 접근이 할 수 없다.
  • 항상 Order를 통해서만 접근이나 수정이 가능하다.


애자일(Aglie)의 철학

애자일은 왜 나온걸까?
애자일은 “불확실한 환경에서 고객가치를 빠르게 검증/학습/적응하는 방식”을 말한다.

핵심은 짧은 주기/작은 배치/지속가능한 속도이다.

  • 사람과 대화를 프로세스와 도구보다 더 중시한다.
  • 작동하는 소프트웨어를 포괄적 문서보다 더 중시한다.
  • 고객과의 협력을 계약 협상보다 더 중시한다.
  • 변화에의 대응을 계획 고수보다 더 중시한다.


왜 등장하게 되었을까?

전통적인 폭포수(요구-설계-구현-테스트-배포) 방식은 아래와 같은 문제가 있다.

  • 긴 사이클로 요구변경 대응이 느리다.
  • 문서/승인 중심으로 피드백이 늦게 도착한다.
  • 출시 시점에 시장/고객 상황이 바뀌어 실패 위험이 증가한다.


2000년 이전까지는 상관이 없었지만, 소프트웨어 환경이 점점 변화함에 따라 새로운 시도를 해야 했다.

  • 웹/모바일 등장으로 시장 변화 속도가 급격히 증가했다.
  • 고객 니즈가 출시 중간에도 수시로 바뀐다.
  • 경쟁 서비스가 빠르게 실험/개선을 한다.

이런 상황에서 폭포수 모델은 빨리 실패하고 학습하기가 불가능했고 이 한계를 극복하기 위해 XP/스크럼/ 린 등 다양한 방식이 나왔다. 이들의 공통점은 짧은 주기, 고객 협력, 변화 수응이다.