소프트웨어의 복잡성은 왜 생겨나는가?

우리가 만들어가는 소프트웨어가 왜 복잡해지고, 통제가 안되는지? 문제에 대한 인지로 도메인 주도 설계(이하 DDD)의 이야기는 시작합니다.

나쁜 설계

우리는 어떤 설계를 하고 있을까? 우리는 설계대신 "작업 보드 셔플" 이라는것을 진행하게되며

할일과 작업중 그리고 완료로 이어지는 작업의 아이템 변화과정을 지식 집약적인 일의 전부로 여기고

나머지는 프로그래머가 소스를 쏟아내기만 하면 된다라고 생각한다. 

이는 잘 드러나지도 않고, 존재하지도 않는 설계에 엄청난 비즈니스 비용을 쏟아붓는일이다.

좋은 설계의 다음 대안은 나쁜설계이다.  이 문구의 요점은 설계를 절대하지 않는것에대한 이야기이다.

처음부터 좋은 설계를 할수 없으며, 이것이 좋은지,나쁜지 작동하기전 까지 알수없을 수도 있다

나쁜설계가 , 설계활동이 없는것보다 더 낫다란 의미이며

완벽한 설계로 지연되는 것이아닌 설계활동 그자체가 우리의 문제를 정의하고 해결하는 핵심이며

설계가 없는것은 지식획득이라는 중요한 것을 놓치고 ,큰 진흙 덩어리를 계속 만들어 내게되며 

소프트웨어 개발을 이익중심이 아닌 원가 중심으로 생각하는 비즈니스 문화가 확고한 경우 설계문화가

생겨날수 없다란것을 경고도 하고 있다.  

큰 진흙 덩어리

 여기서 큰 진흙 덩어리는 , 여러개의 비즈니스 모델이 하나의 서비스에 뭉쳐 작동되는 솔리드 시스템 자체에 대해 문제를 말하는것이 아니다.

비즈니스 모델의 특성과 작동방식을 구분하는 경계가 어떠한 형태로든 존재하지않거나, 파악되지 않는 현상이된 그 자체이며

그러한 현상이 되어가는 원인으로는 비즈니스 로직이 생길때마다, 프로젝트 예측을 매우강하게 요구하여 설계에 들이는 노력이 소프트웨어가 지연되는

결과로 이어질수 있다라는 인식과 함께, 개발팀은 심사숙고한 설계보다.  "작업셔플"만을 사용을하여  점점 큰 진흙덩어리를 만들어 내고 있다란 것이다. 

이렇게 거대해진 덩어리는, 다음과같이 두더지 게임이 되는 상황을 예고하고 있다.

 

큰 진흙덩어리의 문제를 이해하기 위한 그림

 

진흙덩어리에서는 두더지 한마리 잡으면 , 예측하지 못하는 다른곳에서 두더지가 또 발생하는 상황에대해

설명을 하고 있다.  이러한 덩어리가 되는것에 대한 원인은 비즈니스모델 자체의 변화와 복잡성때문이며

도메인을 중심에 놓고 복잡성을 다뤄야 한다라고 이어집니다. DDD이전에는 몇가지 복잡한 문제를 풀기위해

기술중심의 접근방식을 택했다고 하면 해결방식의 사고 전환으로 볼수가 있습니다.

도메인의 복잡성 다루기

소프트웨어가 일반적으로 복잡해지는 이유는, 우리가 사용하는 기술자체의 복잡성 때문이 아니라

우리가 가진 도메인 자체의 복잡성에 기인하며, 도메인을 중심에 놓고 도메인 전문가 까지 

모델을 만드는 단계에 참석을 시키는, 개발문화의 변화와 성숙에 대한 도전 과제로이야기가 이어집니다.

 

DDD의 전략요소 살펴보기

모델

모델을 만들거나 이용하는것은 우리 생활속의 일부이다. 레고를 만드는것, 보드게임을 하는것등이 포함된다.

소프트웨어에서도 도메인을 분석하여 모델을 만드는일은 늘 해오던일이다.

하지만 우리는 이러한 모델을 만드는것에대한 노력을 하지않고 있으며, 하고있지만 인지하지 못하는경우도 있다.

또한 '분석을 위한 모델' , '설계를 위한 모델'  이분법에대해서도 경고를 하고 있다.

이분법을 채택하면서 결국 실제코드와 처음 구상된 모델에 간격이 벌어지면서 모델에 내재된 도메인을 잃게된다는 것이다.

모델을 만드는 과정은 도메인전문과와 팀의 합의된 방식으로 완성된 코드 자체가 모델을 반영해야한다란것이다.

 

모델링의 표현방법으로는 개발자만 사용가능한 전문적인 다이어그램일 필요가 없다.

모델은 다이어그램 자체가 아니라, 그것을 전달하고자 하는 아이디어이기때문이다. 

예> 화물의 이동에따라 ,화물에대한 책임변화를 나타낸 모델, 이와 같은 모델을 함께 발견해 나가야합니다.

 

위와같이 모델개발은 자연어와 함께, 전달하고자 하는 아이디어에 대한 그림한장 이면 충분하며,

도메인 전문가와 지속적인 모델을 만들어내는것에 대해 노력을 해야한 다란점을 강조하고있다.

  • 개발자와 도메인 전문가 모두 문서가 대화를 지배하는 상황을 피해야한다.
  • 최고의 보편언어는 서로 협업하며 나오는 피드백에의해 만들어진다.
  • 이 과정에서 팀의 화합된 멘탈 모델을 만들수 있으며, 이러한 지식탐구는 도메인에대한 통찰로 이루어진다.

 

덩어리를 나누고 바켓에 담기

여기서는 큰 진흙덩어리(진흙공)이 되는것을 어떻게 방지하고 또한 기존 덩어리를 분리(리팩토링)

할것인가에대한 이야기입니다.

 

진흙공(mud ball) 덩어리 나누기 : 바운디드 컨텍스트

 DDD에서는 서로다른 개념들을 , 다른 바운디드 컨텍스트 안으로 분리해 놓음으로 개념간 차이를 중시하고

각기 다른 언어와 그에 따른 기능이 존재하는것을 인정하는것이다. 도메인의 특성을 이해하고(도메인 전문가와 충분한 이야기후), 

바운디드 컨텍스트를 올바르게 나누는 과정에대해 설명이 진행된다.

사실상 가장중 요한 단계이자 어려운 단계이다.   이 과정이 잘 수행되고 나면  다음 해야할것은 이것을 누가 할것인가?

팀을 구분하고 바운디드 컨텍스트를 팀의 바구니에 담는것이다.  

바켓에담기

  • 바운디드 컨텍스트는 단일팀에 할당이되고, 독립적인 소스코드 리파지토리가 있어야한다.
  • 한팀은 다수의 바운디드 컨텍스트에 대해 일을 할수 있다.
  • 다수의 팀이 하나의 바운디드 컨텍스트를 함께 수행할수는 없다.
  • 공식 인터페이스를 통해, 다른팀의 바운디드 컨텍스트를 이용할수 있다.

보편언어개발

팀에서 해야할 바운디드 컨텍스트가 정해졌으면, 여기서 사용되는 언어를 바운디드 컨텍스트 내에서

발견을 가속화하는것이다.  

  • 바운디드 컨텍스트내에서 , 유용한 보편언어를 개발한다.
  • 보편언어는 개발자와 도메인전문가와 번역이 필요없는 합의된 용어이다.

발견과 학습을 가속화 하는 방법으로는 이벤트 스토밍이 소개된다.

이벤트 스토밍

도메인 전문가와 개발자가 같이 참여를 하여,어떻게 전략적 설계를 효율적으로 할것인가에 대한 방법중 하나로

이벤트 스토밍이 소개되고 있다.  그리고 여기서 생성된 유용한 이벤트는 실제 도메인 이벤트로 구현이된다.

  • 시간이 지남에 따라 발생하는 이벤트를 과거형으로 나열
  • 개발적요소(클래스,데이터베이스)가 아닌 이벤트와 비즈니스 프로세스에 집중
  • 팀은 이해의 폭을 획기적으로 증신시키고, 비즈니스모델을 잘 이해한다고 생각한 전문가도 이해의 폭을 다시 넗히고 새로운 통찰력을 가지게됨
  • 모든사람이 무언가를 배우게된다.

 

참고:  DDD와 함께 EventStorming을 도입할수 있는 다양한 툴들이 등장하기 시작함

 

컨텍스트 매핑

여기서는 다른팀에서 혹은 분리되어 각각 개발된 바운디드 컨텍스트가 서로 통합하여 상호운영할수 있는가?에 대한

전략적인 내용과 준수해야할 사항및 관계 표현방법을 포함하고 있다.

  • 파트너쉽 : 매우밀접한 관계가 있어서, 함께 성공하거나 함께망한다. 서로의 의존성이 줄어들어 이점이 사라진다고하면 다른관계로 매핑을 설정해야함
  • 고객-공급자 : 고객이 언제 무엇을 받게될지 공급자가 결정을 하지만 고객의 요구를 받아들이기도함
  • 준수자 : 상류팀이 하류팀의 요구사항에 지원할 동기가 없는 경우, 하류팀이 상류팀의 모델을 그대로 따라야할때
  • 반부패계층 :  가장 방어적이며 , 상류모델로부터 독립을 시키고 번역계층을 만들어 통합에 용이한 모델 개념을 독립적으로 만들수 있음 
  • 공개 호스트 서비스 : 이 프로토콜은 공개가 되어있고 API화가 잘되어 있다. 반부패계층을 만들시간이 없다고하면 이 모델의 준수자가 되는것을 선택할수도 있다.
  • 각자의길 : 바운디드안에서만 의미가 있고 다른 컨텍스트와 통합이 될필요없는경우 

 

 

 

  • No labels