소프트웨어를 설계 해보자, Domain Driven Development (DDD)

5월 15일, 나는 새로운 회사로 이직했고 적지만 이전 회사에서의 경험을 인정받아 팀원들을 리드하게 되었다.

현재 이곳은 태양 에너지 관련 프로젝트 관리 시스템을 개발 및 유지보수 해야하며

이 수익으로 우리 회사를 유지하면서, 우리만의 서비스를 만들어 자립해야한다.

 

...

 

왜 DDD?

우리 팀의 첫번째 임무는 이미 노코드 툴로 만들어진 프로젝트 관리 시스템을 성능상의 이슈로 인해 새롭게 마이그레이션 하는 것이었다.

UI/UX 차원에서 걷어내고 개선해야할 것이 많고 Database Modeling, Cloud Storage, 등을 새로 설계하고 만들어야 한다.

기존 데이터를 새로운 서버에 마이그레이션도 해야한다.

 

물론 단계적으로 만들어 가는것이지만, 팀 내부에서만 소통하며 개발할 수 있는 상황이 아니고

이미 해외에서 꽤 큰 수익을 내며 운영중인 시스템이어서 조심스러웠기 때문에

우리 팀이 이해하고있는 비즈니스 도메인에 대한 이해와 기존 시스템의 쓰임새를 클라이언트와 대화를 통해 검증하고 싶었다.

 

DDD?

나는 DDD가 무엇인지 명확히 알지 못했다.

관련글도 가끔 읽고, 한번쯤 시도는 해보았지만 뭔가 크고 복잡하게 느껴졌기 때문에 아직 깊게 공부해보진 않았다.

정확히는 DDD가 디자인패턴, 크게는 Microservice Architecture(MSA)를 위한 인프라 설계 개념이라고 생각했다.

그리고 도메인이 명확히 무엇인지는 모르겠지만.. 하여튼 "도메인" 주도 개발이니까 도메인에 대한 이해 일치가 필요한 지금 상황에 적합할 것이라는 생각이 들었다.

 

팀원들에게 무언가를 제안하거나 설득 해야할때는 타당한 근거와 목적이 필요하기때문에

급하게 인프런 계정에 봉인되어 있던 DDD 강의를 열었다.

 

DDD는 철학이다.

비즈니스 도메인 용어를 소프트웨어에 최대한 녹여내는 것이며, 비즈니스 관계자와 개발자를 포함한 팀의 모든 구성원이 도메인에 대해 같은 용어를 쓰고 비즈니스 흐름에 대해 같은 이해를 가지는 것이다.

결론적으로 구성원간의 커뮤니케이션 효율을 높이고, 시스템 설계를 직관적으로 하여 복잡도를 낮춘다.

 

이벤트 스토밍

"DDD를 해봅시다!"

라고 말하면 누군가 "그럽시다!" 라고 하기 쉽지 않다.

 

이번에 Jira에 대해 간단한 세미나를 준비하며 기억에 남는 문장이 있었다.

 

애자일은 철학이며, 자연스럽게 애자일 철학을 팀과 프로세스에 적용시키기 위해 스크럼이라는 프레임워크를 사용한다.

 

DDD 철학을 처음부터 명확히 이해하고 업무에 적용하기란 불가능하다.

이벤트 스토밍은 참여 설계 방식 통해 DDD 철학을 설계에 녹여낸다.

 

DDD 우리에게 적합한가?

새로운 무언가를 도입할 때 경계해야하는 것들에 대해 대표님께서 일러주셨다.

 

그래서 우리는 DDD의 장단점에 대해 짧은 시간 리서치를 해보았고

결론은, DDD 러닝커브와 초반 설계 비용이 단점이었다.

 

하지만 위의 단점은 인프라 구성시 발생하는 단점이므로, 설계하는 과정에서 얻을 수 있는

장점이 되는 부분에만 집중을 하는 방향으로 진행을 해보기로 했다.

 

DDD를 도입한다고 해서 무조건 서버를 나눠 MSA로 구성하거나, API 설계나 코드 레벨에서 디자인 패턴을 적용 하지 않아도 된다고 생각한다.

 

도메인 이해 및 보편적 언어 정의를 통해 효율적인 커뮤니케이션을 할 수 있는 것에 집중!

 

 

이벤트 스토밍 2일차

사실 진행을 하면서 반신반의했다. 물론 의식적으로 팀원들에게 이 방법이 비효율적이지는 않은지 물어보고 스스로 고민하며 의심을 한 것도 있다.

 

처음 경험하는 설계 방식이었기 때문에 모두가 확신 없이 진행을 하고 있었고, 토론과 수정도 많이 겪었다.

이 과정이 필요하다고 느끼고 있으면서도 2일째가 되는 날까지도 클라이언트에게 보여줄만한 결과가 나오지 않았기 때문에 걱정도 됐었다.

 

이벤트 스토밍을 진행하며 우리의 목표를 몇번이고 점검했다.

 

- 클라이언트가 쉽게 이해하고 참여할 수 있어야 한다.

- 용어와 시스템 흐름에 대한 이해를 일치시킨다.

- 설계 과정에서 핫스팟(질문)을 많이 도출해야한다.

,등

 

그 결과 2일째 퇴근시간 즈음 그럴듯한 결과물이 나왔다.

 

처음에는 그냥 진행하다가, 확신이 들지 않아 강의에서 단계별 실습 내용을 보며 진행했다.

이벤트를 도출하고 커맨드, 액터, 등을 단계적으로 도출하는 과정에서

사실 각각이 다 거의 똑같은 단어들이었기에 이게 의미가 있는 것일까? 라는 생각이 들었다.

 

- 이벤트: 회원가입됨

- 커맨드:회원가입

- 액터: 비회원

 

하지만 막상 진행을 해보니 우리가 명확하게 설정하지 못했던 부분들과 고려하지 못할수 있었던 것들을 자연스럽게 보강하게 되었다.

 

Tip

 

이벤트 스토밍을 진행하며 겪은 시행착오중 하나를 공유해보려한다. 이벤트명과 액터명이 매치가 적절치 않을 수 있으나 이것은 핵심이 아니기에 신경쓰지 말자.

 

우리는 프로젝트 상세 정보를 조회할때 액터가 어떤 권한이 있는 유저여야하는지 고민했었다.

하지만 하나의 문맥에서 액터가 여러개로 불려질수 있다면 문맥을 파악하기 어려워진다.

우리는 대화를 할 때 액터에 대한 이름만 들어도 어떤 이야기를 하고있는지 문맥을 파악할 수 있어야 한다.

 

따라서 실제 Role을 액터로 하는 것이 아닌, 이벤트를 일으킨 주체를 뭐라고 부를 것인지 용어를 정의해야한다.

그리고 그 주체가 될수 있는 Role은 어떤 것이 있는지 정의해볼수 있겠다.

 

참고로 설계 단계에서 합의하고 정의한 용어를 유비쿼터스 랭귀지라고 한다.

 

이 유비쿼터스 랭귀지를 정의하여 커뮤니케이션 효율을 높이고 소프트웨어 추상화에 활용하여 복잡성을 낮출 수 있다.