[우아콘 2021] 도메인 원정대

💡 원본영상 : https://www.youtube.com/watch?v=kmUneexSxk0

 

세미나 내용

• 도메인 지식을 탐구하고, 문제 영역과 해결 영역을 좁히고 분산하여 복잡한 비지니스를 문제를 해결하는 방법을 소개합니다.

• 해당 세미나의 대상은 아래와 같습니다.

• 미리 핵심 요약을 이야기 해보면 아래와 같습니다.

문제 영역 탐구

• 위의 글을 읽고 해결책을 먼저 찾으려고 한다면, “엘리베이터의 속도를 높인다.”, “새로운 엘리베이터를 만들어 추가한다.”, “짝수층과 홀수층의 엘리베이터를 분리한다”로 정리할 수 있다.

• 그러나 이런 답을 먼저 하기 전에 누구의 문제인지 / 어떤것이 문제인지 / 왜 문제인지에 대한 질문을 먼저 던지는 것이 좋다.

• 앞서 나열된 해결책들은 다양해 보이지만, 모두 “엘리베이터 사용자들(사무실 입주자들)의 문제를 가진 사람들”을 위한 것이라고 생각합니다.

• 그럼 여기서 건물주의 입장에서 한번 생각해보면 어떨까요?

• 결국 어떤 문제를 해결하고 싶은지 정확히 파악해야 어떤 해결책이 좋은지 생각할 수 있습니다.

• 또 다른 문제를 한번 살펴봅시다.

• 이 글을 보고, 이미 벌써 재고 보고서를 인쇄하기 위한 라이브러리를 공부하고 있을지도 모릅니다.

• 이 글에서 이미 “재고 보고서를 인쇄할 수 있어야 한다.”라는 말에서 이미 해결책이 나온것처럼 보이지만, 누구의 문제인지 / 어떤 것이 문제인지 / 왜 문제인지의 질문을 던져보면 다른 관점이 보일수 있습니다.

• 사실 물류 센터 관리자의 관점에서 보면, 해당 글을 읽고 “재고가 없을 때 품목을 주문할수 있도록” 즉, “물품이 떨어지기 전에 품목을 주문할 수 있도록 보다 효율적인 출고 프로세스”가 필요하다는걸 알수 있습니다.

• 그렇다면, 출고 예측 시스템을 도입해서 물류 센터 재고를 수동으로 추가하지 않고 자동으로 할 수 있도록 더 나은 개선책을 찾을수 있습니다.

• 따라서 문제를 어떻게 바라보느냐에 따라서 해결책이 굉장히 달라진다는 것을 배웠습니다.

• EO의

• 여러분들은 재고 보고서를 인쇄하기 위해 라이브러리를 공부하고 있을지 모릅니다.

• 재고 보고서를 인쇄할수 있어야 한다라는것이 이미 해결책이 나온것처럼 보이지만, 누구의 문제인지 어떤것이 문제인지, 왜 문제인지를 질문을 던져보면 사실 물류 센터 관리자는 물품이 떨어지기 전에 품목을 주문할 수 있도록 보다 효율적인 출고 프로세스가 필요했었고, 출고 예측 시스템을 도입하여 물류 센터에 재고를 수동으로 추가하지 않도록 개선할수 있을 것입니다.

• 저희는 문제를 어떻게 바라보느냐에 따라서 해결책이 굉장히 달라진다는 것을 배웠습니다.

• EO의 김범준 대표 유튜브를 보면 여기서 우리가 풀고자 하는 문제가 무엇인지를 정확히 이해하는 것에 노력이 80%가 들어가야 하지 않을까? 라는 말을 하기도 했습니다.

도메인

• 소프트웨어로 해결하고자 하는 문제 영역

• 소프트웨어를 사용하는 사용자의 활동이나 관심사와 관련되어 있다.

• 소프트웨어 산업은 다른 산업 내에서 발생하는 다양한 비즈니스 문제를 해결한다.

소프트웨어는 사람의 욕망과 욕구를 해결하려고 만든 창조물입니다. 사람들의 욕망과 욕구가 개발자에게 전달됐을 때 우리는 그것을 도메인이라고 부릅니다. - 조영호

• 위와 같이 도메인을 정의내릴 수 있습니다. 예를 들어 쇼핑몰을 구축할때 도메인은 전자상거래이며 사용자가 무엇을 말하고 이해하기 위해서는 전자상거래 지식이 필요합니다.

도메인 모델

• 모델은 목적을 위해 현실 세계에 존재하는 것을 가공하고 편집하여 우리에게 정보를 제공한다.

• 특정 다이어그램이 아니라 다이어그램으로 전달하려는 아이디어이자 목적을 가진 의사소통 수단이다.

• 이 의사소통 수단은 회의, 기획, 디자인, 개발에 사용되어야 한다.

• 위의 사진 처럼 각자 다른걸 보고 있는 것을 같은 걸 생각하기 위한 것입니다.

• 항공권예약 시스템에서 항공기, 승객들 물리적으로 존재하는 것을 모델링 할수 있으며, 회계 시스템에서는 현금, 금융 등 물리적으로 존재하지 않는것을 모델링 할수 있습니다.

• 도메인 모델을 사용하는 여러 이해관계자가 동일한 모습으로 도메인을 이해하고 지식을 공유하는데 도움이 될것이다.

강의 도메인

• 많은 문제를 해결하기 때문에 많은 혼란을 일으키기도 합니다. 예를들어 회의중에 강의라는 단어가 맥락을 고려하지 않으면 강의 콘텐츠를 강의인지 수강 신청을 받는 강의인지 헷갈릴수 있습니다.

• 이때 도메인 탐구를 활용해야 하며, 이걸 이벤트 스토밍이라고 합니다.

바운디드 컨텍스트

• 앞에서 강의라는 개념이 혼란스럽다고 설명했습니다. 그렇기 때문에 이제는 강의에 연관된 문제를 해결하기 위해서 풀어야 할 영역을 좁혀야 합니다. 이를 바운디드 컨텍스트라고 합니다. 이 말이 어렵다면 해결 영역이라고 생각하면 좋습니다.

• 즉, 관심사를 분리하고 격리하여 문제 해결에 집중할 범위를 정한다.

• 예를들어 FAQ와 같습니다. 계정 관련된 질문은 계정 메뉴를 결제 환불관련된 문제는 결제환불 메뉴를 통해 해결하는것과 동일합니다.

• 아래 피자로 예시를 들수 있습니다

• 왼쪽에 있는 것은 관심이 없는 영역일수도 있지만, 뒤에 있는 영역은 관심이 있는 영역일수도 있습니다.

• 강의 도메인을 각각의 해결 영역에 넣어보았습니다.

해결 영역 탐구

• 이제 수강신청 수강생 관리 해결 영역에서 비지니스 문제를 해결하는 방법을 살펴보겠습니다.

• 규칙에 따라 엔티티의 모델링을 해봤습니다.

• 독립적인 식별자가 있으니 꽤 합리적인 구조로 보입니다.

• 결제를 마친 배달이가 수강신청하러 옵니다. 이때 정원과 모집상태를 고려하여 수강 신청이 가능한지 여부를 묻습니다. 만약 수강신청이 가능하다면 새로운 수강생으로 등록됩니다.

• 여기서 비지니스 규칙을 잘 지켜서 동작했을까요? 현실은 전혀 예상치 못한 방향으로 흘렀습니다. 정원은 30명인데 수강생은 60명이 되었습니다.

• 강의 학생수가 많으면 좋지만 강사가 생각한 수강생 수보다 더 많다면 강의장도 더 빌려야 하고 리뷰어도 더 모집해야 하기 때문에 더 많은 일이 생겼습니다.

• 대체 무엇이 문제엿을까요?

애그리거트

• 예를들어 장바구니 합계는 항상 각 상품 수량에 해당 단가에 곱한 값이 여야 한다. 라는 불변식이 있다면 어떤일이 있으며, 불변식이 깨져서는 안됩니다.

• 실제로 주어진 클래스들의 계약을 정하는 방법이며 내부의 구현은 자유롭게 할 수 있습니다. 캡슐이라고도 할수 있고 비지니스 규칙이라고도 생각하면 좋습니다.

• 애그리것트로 묶으면 좀더 상위 레벨에서 도메인 모델간의 관계를 파악할 수 있으며, 객체는 유사하거나 동일한 생애주기를 가집니다.

• 애그리거트에는 속한 객체를 관리하는 루트 엔티티가 있습니다.

• 루트 엔티티의 핵심 역할은 애그리거트의 일관성이 깨지지 않는 것이며, 애그리거트의 속한 엔티티와 값 객체를 사용해서 애그리거트가 구현해야 할 기능을 제공합니다. 이는 애그리거트의 내부 구현을 숨김으로써 캡슐화 하는데 도움이 됩니다.

• 루트 엔티티의 식별자를 애그리거트 외부에서 사용할 수 있는 전역 식별자라고 하며, 이 전역 식별자를 통해 애그리거트를 조회할 수 있습니다.

• 수강생과 수강 대기자는 자식 엔티티이며, 회원 ID라는 지역 식별자를 가지고 있습니다. 회원 ID를 전역 식별자라고 생각할 수 있지만, 회원 어그리게트에선 전역 식별자일수 있지만, 한명의 회원이 여러개의 강의를 수강할 수 있으니깐 회원 ID로만 수강생을 식별할 수 없습니다. 그래서 특정 강의 내에서만 식별할수 있으니 지역 식별자라고 합니다.

• 잠금은 다중 사용자 환경에서도 비지니스 규칙이 깨지지 않게 하는 방법입니다.

잠금

• 비관적 잠금
  • 한 번에 한 명의 사용자만 처리할 수 있도록 데이터베이스의 레코드를 독점한다.
  • 성능이 저하되고 교착 상태가 발생할 수 있다.
• 낙관적 잠금
  • 애그리거트에서 무엇이든 변경하면 버전 증가가 발생해야 한다.
  • OPTIMISTIC_FORCE_INCREMENT를 사용하거나 버전을 수동으로 증가시킨다.

• 수강생과 수강 대기자는 자식 엔티티이며, 회원 ID라는 지역 식별자를 가지고 있습니다. 회원 ID를 전역 식별자라고 생각할 수 있지만, 회원 어그리게트에선 전역 식별자일수 있지만, 한명의 회원이 여러개의 강의를 수강할 수 있으니깐 회원 ID로만 수강생을 식별할 수 없습니다. 그래서 특정 강의 내에서만 식별할수 있으니 지역 식별자라고 합니다.

다시 잘 동작하는지 확인해보기.

• 결제를 마친 배달이가 수강신청하러 옵니다. 이때 정원과 모집상태를 고려하여 수강 신청이 가능한지 여부를 묻습니다. 만약 수강신청이 가능하다면 새로운 수강생으로 등록됩니다.

• 그 다음에 강사가 강의정보를 수정하기 위해 접근합니다. 이때 정원과 모집상태, 자동 승인 여부를 수정할 수 있습니다.

• 기존 수강생이였던 배달이가 이름과 이메일을 수정하기 위해 강의 루트 엔티티에 접근합니다.

• 이때 잘 되었을까요?

• 이번에는 트랙잭션 오류인 Optimitc Lock Exception이 발생하게 됩니다. 여기서 버전이 문제가 됩니다. 동시에 접근하는 경우 문제가 발생하며 처음 조회 했던 버전과 누군가에 의해 증가된 데이터베이스에 증가된 버전이 달라 문제가 됩니다. 이때 새로운 수강생이 떠나게 된다면 비지니스에 크게 피해를 받게 됩니다.

도메인 지식

• 여러 강사가 동시에 강의 정보를 수정하지 않는다.

• 수강생들은 동시에 수강 신청할 수 있다.

• 강의 정보 수정과 수강생 정보 수정으로 인해 수강 신청을 막아서는 안된다.

• 여기서 개발자들은 수강생 정보를 변경하려면 모든 수강생을 조회해야 한다. 라는 고민이 생기게 됩니다.

• 따라서 수강생을 별도로 애그리거트로 분리하자고 결론을 내렸고 기존의 불변식을 어떻게 보장할지 고민하게 됩니다.

• 일단 수강생 엔티티를 별도 엔티티로 분리해서 루트 엔티티로 만들고 정원이라는 비지니스 규칙을 지키고 강의를 통해 수강생이 생성되도록 만들면서 수강생은 강의와 관계가 잇다는것을 알려주고, 수강생을 따로 저장하는것을 알리고 싶지 않다면 도메인 서비스를 사용해 감출수도 있습니다

• 이때 동시성 제어는 어떻게 해야 할까요? 이때 강의 수강생이라는 값 객체를 추가하는 것입니다. 이름과 이메일은 불변 식을 지키는데 필요 없기 때문에 분리했으며, 수강생 개념은 엔티티지만, 실제 구현은 VO로 할수 있다.

• 일시적으로 불변식이 깨지지만, 최종적으로 지키기 위해 노력할 수 있습니다. 이걸 결과적 일관성이라고 합니다. 일시적으로 불변식이 깨지지만 최종적으로 지킬수 있도록 노력한다라는 말로 배치나 이벤트 방식으로 처리할 수 있습니다.

• 애그리거트를 잘 쪼개서 설계하는 것은 동시성의 극대화를 가져오고 애그리거트를 너무 크게 설정하면 성능상 문제를 가져오게 된다.

• 즉 설계 단계에서 성능상 문제를 고려하게 됩니다.

• 애그리거트마다 최적의 데이터베이스를 선택해서 사용할수도 있습니다.

• 하나의 애그리거트가 하나의 MSA가 될수도 있습니다.

• 경우에 따라 낙관적 잠금을 사용할수도 있습니다. 중요하지 않는 명령들에 대해서는 잠금을 사용하지 않는 방법을 선택할수도 있습니다.’

결론

• 누구의 문제인지, 어떤 것이 문제인지, 왜 문제인지에 대한 질문을 던져 보자.

• 계층형 아키텍처의 계층을 나누는 것만큼 해결 영역을 나누는 것도 중요하다.

• 데이터베이스의 동시성 제어보다 애플리케이션의 동시성 제어가 더 한눈에 들어온다.

• 도메인 전문가와 함께 모델을 검증하는 것이 코드를 작성하고 테스트하는 것보다 빠를 수 있다.

감상평

• 소프트웨어란, 문제를 해결하는 방법중 하나라고 생각합니다. 그렇다면 그 문제는 누군가가 정의를 내리고 그 누군가가 해결책까지 정의를 내리는 경우가 많겠죠. 그러나 그건 그 누군가의 문제이고 넓은 관점에서 볼수 있는 눈이 필요하다고 생각합니다.

• 그 눈으로 바라볼수 있도록 하는 첫번째 걸음이 “누구의 문제인지 / 어떤것이 문제인지 / 왜 문제인지” 바로 이 질문에 대한 나만의 정의를 내리는 것이라고 생각합니다.

• 즉, 결국 어떤 문제를 해결하고 싶은지 정확히 파악해야 어떤 해결책이 좋은지 생각할 수 있습니다. 이 문장을 기억해야 한다고 생각했습니다.

• 정의한 이후엔 결국 도메인이라는 영역으로 풀어 나갈수 있으며, 해결 영역인 바운디드 컨텍스트가 생긴다고, 도메인 규칙이 생겨서 개발자는 이제 코드로 해결해 나가기만 하면 됩니다.

• 그 과정에서 많은 문제점이 발생해서 도메인 규칙이 깨질수도 있지만, 그걸 하나하나씩 해결 해 나가기 위해 장치들을 마련해두는게 가장 중요하다고 생각합니다.

• 일단 이 문제점들을 최소화 하기 위해선 도메인 / 애그리거트를 잘 설계하는 것이 좋다고 생각합니다.

• 비지니스 규칙을 불변식으로 생각하고, 그 불변을 깨트리지 않는 것이 중요하다는걸 느껴짐. 따라서 규칙을 명확히 이해하고 해결해 나가는 것이 중요하다는걸 느꼈습니다.