Ddd 도입을 위해 한 것

09 Apr, 2022

글

DDD 사례로 커버할 수 있는 것, 할 수 없는 것

전제지식: DDD의 목적

1. 소프트웨어 기능성 상승 => 기능성 = 고객에게 도움되는 것

2. 소프트웨어 보수성 상승 => 보수성 = 긴 시간이 지나도 기능 확장이 용이한 것

DDD의 목적: 고객에 도움이 되는 소프트웨어를 빈번하게 갱신할 수 있도록 한다.

부드럽게 진행된 것

• 마츠오카 주도의 모델링

• 모델도를 근본으로 한 코딩

  • 신규 개발시, 모델도를 보면서 개발한 것이 도움되었음

• 코딩 표준 보급

  • 표준적 코드 본보기가 있으면 구현의 횡전개가 쉬워짐
  • 신규가 아니더라도 이런 식으로 하면 하기 쉬워진다 같이 본보기가 되는 것

• 테스트 구현

  • 테스트 장점을 실감시키면 넓은 마음으로 받아들임

테스트코드 양을 늘었을 때, 모델링하고 싶은데 같이 몹 프로그래밍해주실 수 있나요? 들으면 변화를 실감함

고전한 것, 시도한 것

• 무엇을 만들까에서 어떻게 활용할까로 넘어감
  • 만들기보다 고객에 도움이 되는 것으로 가는 것이 어려움
• 고객의 이해도를 높인다
  • PM, CS와 협력해서 청취, 가설검증을 반복

DDD를 도입 후, 제품 기능성을 높히는 것이 힘들었다 하더라.

제품을 활용하기 위한 구조

• 신기능을 선행체험하는 고정을 정해서 PdM이 청취, 피드백을 받는다
• 기존 기능에 대해 고객의 목소리를 듣는 기회를 갖는다. 거기서 스프린트 안건을 계획

정리

• DDD는 보수성, 기능성 개선에 효과가 크다
• 사내 인원만으로 기능성을 올리기 힘들다
• 아무튼 고객의 목소리를 듣고, 업무를 이해하는 것이 중요

거대 레거시 시스템의 전략평가와 리팩토링에 의한 DDD 활용사례

DDD를 사용해 레거시 시스템의 품질상승에 대한 이야기

DDD 도입이유1 코어 도메인을 결정해 개발 비용 대비 효과 상승을 위해

• 정해진 개발 자원을 유효하게 이용하기 위해 시스템의 코어 도메인이 무엇인가 확인할 필요가 있었다
• 문제영역(실현하고 싶은 것)과 해결영역(실현 수단)을 정리하는 것부터 시작임

코어도메인: 시스템 경쟁우위성을 발휘해서 더욱 부가가치를 높힐 수 있는 영역

시도한 것

• 도메인 전문가 같은 관계자 이야기 청취

예시: 해결하고 싶은 문제 등...

사업영역을 명확히 하고, 코어 도메인을 특정할 수 있었다.

고전한 것

• 필요한 정보량이 많다
  • 입사를 막 했거나, 원격근무 등의 이유로 전문가를 확인 할 수 없어서 이곳저곳 채팅만 찔러본 시간이 길었다
  • 코어도메인 지식을 수집, 정리하기 위한 사람이 더 필요했다

DDD 도입이유2 레거시 시스템의 기술적 부채 해소

• 거대한 Rails 애플리케이션 부채로 유연함이 떨어짐
• 부채를 낳기 어려운 설계하고 싶음

이런 목적으로 설계개선을 했다.

그러나 개발조직 전체에 의도, 목적이 공유되지 않으면 혼란을 일으킬 가능성이 있다.

실제로 초기에는 다른 멤버가 Rails스러운 개발을 해서 부채를 해소할 수 없었다.

고전한 것

• 현장 과제와 DDD 기술을 어떻게 엮어 설명하는가

  • DDD: 코어도메인의 가치를 높혀 장기적으로 성장하기 위한 설계 사상
  • 현장 과제: ActiveRecord를 Repository에 격리해서 도메인 지식을 독립시킴
  • 결과: 기술부채를 염려한 멤버가 많았기에 FatModal 의미의 다른 개념 단위로 분할면에서 찬성하는 멤버가 많았음, 기술부채는 점차 저감

• 고전하고 있는 것

  • 설계가 Rails 사양을 끌려가 품질 저해
    • ActiveRecord를 중심으로 기능을 집약되었기 때문이므로 Rails의 구현으로 설계가 끌려다님

• Ruby의 특징

  • 타입 지원이 없어서 의존관계를 명확히 추적어려움.
  • 리팩토링 효율이 너무 떨어짐

기반 시스템 변경을 편하고 안전하게 한다

위의 케이스는 비교적 젊은 케이스지만 이번 케이스는 전통적인 대규모 기업에 의한 DDD 실전을 다름

계획한 안건

• 손해보험 시스템
• 거대 EC 사이트 기반 사이트

계획한 안건의 주제

• 비즈니스 요구에 응하는 시스템 변경 속도
• 소프트웨어 개발 비용 감소
• 수정 비용 감소

현장에서 하고 있는 것

• why 합의 형성

  • 나쁜 설계로 잃어가는 것을 수치, 언어화
  • 나쁜 설계로 얻고 있었던 것을 수치, 언어화

• how에 대해 인식 공유

  • 비즈니스 규칙(계산판단 로직) 중심 설계
  • 사실 기록 중심 테이블 설계
  • 대략적이 아니라, 진득하게 범주화(요점 간파한다)

결과

DDD 도입으로 시스템 사양 관리가 막대한 Excel 시트에서 업무 매뉴얼 + 소스코드로 변경할 수 있었다.

또한 비즈니스 로직이 도메인 오브젝트로 집약되서 기능 개선에 따른 코드 변경량이 감소되었다.

감상

DDD를 무조건 도입하는 것이 아니라, 소규모한 곳부터 시작해 팀 멤버에 장점을 실감시키는 것이 중요하다 생각한다.

DDD는 소프트웨어 가치를 높히는 수단이며, 가장 중요한 시스템의 코어 도메인을 관계자와의 교류에서 확인하는 것이라는 사실을 도입하면서 알 수 있었음.

엔지니어라 하여, 시스템이 다루는 사업에 무관심할 수 없다는 것을 재확인함.