개발 아키텍쳐를 설계하는 단계에서 자주 등장하는 용어로 '비즈니스 로직, 도메인 로직, 서비스 로직'등이 있다.
- 비즈니스 로직을 분리해라.
- 도메인 로직은 다른 계층에 의존해서는 안된다.
일단 필자는 위와 같이 '대충 알것 같은' 용어들을 좋아하지 않는다. 처음 들어보는 개념이었다면 아예 개념을 익히기 위해 공부했겠지만, '비즈니스', '서비스' 등 실무에서 자주 등장하는 용어로 어감을 통한 추측과 구글링에 나온 대략적인 설명을 보면 이해한 것 같은 기분이 든다. 그렇게 개념을 어중간하게 이해한 상태로 아키텍쳐를 설계하다간 각 계층간 역할이 더 모호해진다.
설계한 아키텍쳐가 잘못되었음을 인지하게 되고 원인을 분석해보면 '비즈니스 로직'과 '서비스 로직'을 명확하게 구분짓지 못해 아키텍쳐를 다시 엎어버리는 불상사가 일어난다.
(현재 필자가 그런 상황이다.. 어중간하게 아는 개념은 아는게 아니라 모르는거다.)
도메인 로직이란?
도메인 로직, 비즈니스 로직이라는 말은 거의 동의어처럼 쓰인다. 소프트웨어 공학에서 도메인, 비즈니스라는 말은, '소프트웨어가 풀고자하는 현실 세상의 문제'를 가리킨다.
즉, 소프트웨어의 핵심 역할을 하는 부분이 될 것이다.
예를 들어, 은행 앱이라면, 금융 및 은행 업무가 도메인이다. 은행 앱이 해결하고자 하는 문제가 금융 업무를 스마트폰에서 처리할 수 있게 해주는 것이니까. 틱톡 같은 SNS라면 동영상 촬영, 감상, 댓글 및 공유일 것이다.
반대로 공학/기술적인 문제에 속하는 것들은 대개 '도메인'과는 구별된다. 수많은 은행 사용자 데이터를 어떻게 효율적으로 저장할 것인가. 어떻게 고화질 동영상을 빠르게 로딩할 것인가? 같은 것들이 된다.
현재 내가 쓰고 있는 코드가 도메인 로직에 속하는 것인지 아닌지에 대한 여부는 한가지 질문을 통해서 구분할 수 있다.
(앞으로 로직을 구분하는 연습을 많이 해보자)
Q. 현실 문제를 해결하는 직접적인 의사결정을 하는가?
위 질문에 대한 대답이
Yes라면 => 도메인 로직
No라면 => 서비스 로직
쉽게 말해, 도메인 로직은 현실 의사 결정을 하는 코드다. 나머지 로직은 그 결정의 결과물을 보여주고 전파하는 코드인거다.
예를 들어, 모바일 송금 앱이 있다고 가정해보자.
여기에서 송금을 담당하는 코드를 보면 아래와 같이 6가지 단계로 나눌 수 있다.
- 계좌 잔액이 충분한지 확인한다.
- 유효하다면 송금 버튼을 활성화하고, 유효하지 않다면 에러 메시지를 띄운다.
- 사용자의 멤버십 등급에 맞춰서 송금 수수료를 계산한다.
- 송금 수수료를 결제하도록 외부 결제 서비스에 요청한다.
- 사용자의 잔액을 감소시킨다.
- 사용자의 잔액을 DB에 저장한다.
각 코드들이 도메인 로직인지 서비스 로직인지 구분해보자.
도메인 로직에 해당하는 것은 다음과 같다.
- 계좌 잔액이 충분한지 확인 -> 송금이 가능한지에 대한 의사결정
- 송금 수수료를 계산 -> 송금에 드는 비용을 정책에 따라서 결정
- 사용자의 잔액을 감소 -> 송금이라는 서비스를 수행
위 코드들은 '송금'에 대한 의사결정을 담당하고 있다.
- 유효하지 않으면 에러 메시지를 띄운다 -> UI
- 송금 수수료를 결제하도록 외부 결제 서비스에 요청한다. -> 외부 서비스와의 네트워킹
- 잔액을 DB에 저장한다. -> Persistence
서비스 로직은 위와 같이 도메인 로직이 의사결정을 할 수 있도록 입력을 제공하며, 결과를 외부 서비스/DB/UI에 업데이트하는 역할을 맡는다.
명확한 관심사의 분리
우리가 도메인 로직과 아닌 것을 나누는 이유는 명확한 관심사의 분리를 위해서다.
도메인 로직과 아닌 것을 잘 나누고 결합도를 낮추면, 개발자가 DB나 UI 같은 기술적인 구현 사항에 신경 쓰지 않 도메인 로직을 이해하기 쉬워진다. 이는 유지 보수성, 재사용성을 높여준다.
또한 비즈니스 정책이 변경됨에 따라 소프트웨어를 변경하고 기능을 추가하는 것이 편해진다.
이런 이유로 클린 아키텍처에서는 도메인 로직을 앱의 코어로 두고, 다른 계층에 의존하지 않도록 설계한다. 다른 계층들은 도메인 로직에게 입력을 전달하고, 변화를 외부로 전달하는 역할을 하도록 명확하게 분리한다.
참조
