WebArchitecture

도메인 로직 이해

,

비즈니스 로직/도메인 로직 이해

개발 아키텍처에서 말하는 비즈니스 로직/도메인 로직 이해를 하려면

도메인 로직인지 아닌지 판단 기준을

"이 코드가 현실문제에 대한 의사 결정을 하고 있는가?" 로 접근하면 개념을 이해하기가 쉬울 것이다.

개발하면서 자주 듣는 말…

“비지니스 로직을 분리하세요.”
“도메인 로직은 다른 계층에 의존해서는 안됩니다.”

도메인, 비지니스 이란 단어는 일반적인 일상에서의 이해하고 쓰는 개념으로 접근하면 도메인은 주소? 비지니스는 사업? 으로 풀이해서 접근 해볼 수 있는데, 소프트웨어 공학에서 사용하는 도메인, 비지니스란 용어의 개념은 조금 다르다.

소프트웨어가 풀고자 하는 ‘현실 세상의 문제’ 를 가르키는 말로 풀이 될 수 있다.

이 개념을 바탕으로 예를 들어 도메인이 무엇인가로 접근해본다면

[은행 앱]

아래 리스트는 은행 앱이라는 소프트웨어가 가지고 있는 도메인이라고 볼 수 있다.

  • 이자율
  • 잔액
  • 출금
  • 계좌 개설
  • 계좌 해지

은행 앱이 해결하려는 현실의 문제는 고객의 금융업무를 처리해주는 것이기 때문이다.

[틱톡]

아래 리스트는 틱톡 앱이라는 소프트웨어가 가지고 있는 도메인이라고 볼 수 있다.

  • 영상 편집
  • 제목 수정
  • 댓글 조회
  • 공유

다시 말해 이 코드는 도메인 로직 이다 또는 이 코드는 비지니스 로직이다 라고 할 때, 그 뜻은 이 코드가 현실 세상의 문제에 대해서 결정을 하고 있다라는 뜻 이다.

그럼 의문이 들 수 있는게 소프트웨어는 결국 다 현실의 문제를 해결하는거 아닌가? 라고 이렇게 생각할 수도 있다.

그치만 은행 앱이나 SMS 앱의 코드를 한 줄 한 줄 뜯어보게 되면 실제 현실 세계의 대한 결정 말고도 굉장히 많은 코드들을 써야 한다 라는 것을 알 수 있다.

  • 데이터 베이스 연결하기
  • 백엔드 서버에 API 호출하기
  • 수많은 은행 고객 데이터를 효율적으로 적용하기
  • 고화질 동영상을 캐싱해서 빠르게 로딩하기
  • 화면이 밑에서 떠오르는 애니메이션 UI 추가하기

이런것들은 도메인 로직에 해당되지 않으며 어플리케이션 서비스 로직 (비지니스 로직) 이라고 볼 수 있다.

이 코드가 현실 세상의 문제에 대해서 결정하고 있는가로 접근해서 접근하고 있으면 도메인 로직에 해당 될 수 있는 거고 나머지들은 그 결정을 위한 입력값을 만들어 주거나 그 결정의 결과물을 보여주고 전파하는 코드인 거라고 보면 된다.

구체적인 예를 들어 모바일 송금 앱 이라는 서비스가 있다고 가정하고 아래 예시 중 어떤것이 도메인 로직이고 어떤것이 서비스 로직에 해당 될 수 있을까 판단해 보자.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
송금을 담당하는 코드를 생각해 보면 대략 6 가지 단계로 나눠 볼 수 있다.

1. 계좌의 잔액이 충분한지 확인 한다. (도메인 로직)
   a. 송금이 가능한지에 대한 의사 결정하는 것
2. 송금 버튼을 활성화하거나, 유효하지 않다면 에러 메시지를 띄운다. (서비스 로직)
   a. UI 로직에 해당.
3. 사용자의 멤버십 등급에 맞춰서 송금 수수료를 계산 한다. (도메인 로직)
   a. 송금에 드는 비용을 수수료 정책이나 멤버십 정책에 따라서 결정하는 것
4. 계산한 송금 수수료를 결제 하도록 회부 서비스에 요청 한다. (서비스 로직)
   a. 외부 서비스와의 네트워킹에 해당.
5. 수수료와 송금액만큼 사용자의 잔액을 감소 시킨다. (도메인 로직)
   a. 사용자의 잔액에서 수수료와 송금액 만큼을 빼서 잔액을 감소 시킨다.
   b. 이제 송금 후 이제 얼마인지를 계산하는 것
6. 사용자의 잔액을 **DB** 에 저장 한다. (서비스 로직)
   a. DB와 관련된 영속성 로직에 해당.

도메인 로직에 해당 되는 단계를 살펴보면…
이 코드들은 송금이라는 현실 세계의 문제에 대한 의사 결정을 담당하고 있다.

서비스 로직에 해당 되는 단계를 살펴보면…
도메인 로직이 의사결정을 할 수 있도록 입력을 제공하거나 그 결과를 외부 서비스, DB, UI 등에 업데이트 하는 역할을 맡는다.

실제로는 깔끔하게 구분되어 지지 않는 경우가 훨씬 더 많다. 어떤 코드를 봤는데 도메인 로직인지 서비스 로직인지 애매하면 대부분 그 둘이 섞여 있는 경우가 높을 것이다. 이럴 경우 함수로 명확하게 구분짓고 나누어서 해결 해 볼 수 있을 것이다.

이렇게 도메인 로직과 서비스 로직 이 둘을 구분 하게 되면 테스트를 해야 될 것과 안해야 될 것이 명확하게 분리 될 수 있어 테스트 가성비도 올라가게 된다.

그리고 결과적으로 개발자가 도메인 로직을 이해하기 쉬워지게 된다. 왜냐하면 UI, DB 같은 기술적인 구현사항에 신경쓰지 않고 현실 세계의 의사결정을 잘 반영하고 있는지 그 정책에 대해서만 이해를 할 수가 있다.

실제로 비지니스 정책이 변경되게 될 경우, 소프트웨어를 변경하고 기능을 추가하는 것도 굉장히 편해지게 된다.

도메인 로직과 서비스 로직의 구분은 결국 서비스 개발함에 있어 나쁜 아키텍처를 만들지 않기 위해서 꼭 필요한 내용 일 것이다. 그렇기에 이런 개념을 잘 잡고 가는게 좋다.

참고

공유하기