프로젝트를 진행하며 클린 아키텍처를 도입하면서 UseCase를 사용하게 되었는데요
처음 사용하는 UseCase에 대해 찾아보는데 ..
UseCase를 사용하면서 UseCase는 비즈니스 로직을 실행한다, UseCase를 설계할 때 비즈니스 로직에 기반한다.. 등등
대체 비즈니스 로직이 정확히 뭐지..?? 🤯
UseCase를 제대로 사용하기 전에 비지니스 로직에 대해 먼저 이해하기 위해 정리해보았습니다
🤔 우선, 로직 분리를 왜 해야하지 ?
바로 소프트웨어 설계의 근본인 "관심사의 분리"를 위해서 !
조금 더 쉽게 풀어서 말하면
코드를 하나의 커다란 뭉텅이로 만들지 말고, 작게 쪼개서 역할을 나누자 !
하나의 앱을 만들기 위해선 간단해보이는 작은 앱일지라도 생각보다 많은 코드가 필요합니다
그렇다 보면 점점 복잡해지고, 이 복잡한 코드를 잘 다루는 방법은 바로 '잘 나누는 것' 입니다
📎 '비즈니스'란 ?
여기서 의미하는 비즈니스란 소프트웨어가 풀고자하는 현실 세상의 문제를 의미합니다
사실 저는 이 말도 잘 와닿지 않았는데요.. 😅
즉, '소프트웨어를 개발하는 이유'를 말합니다
예를 들어 은행 앱의 경우 금융 및 은행 업무 (잔액 확인, 송금 등 ..)를 하기 위해 개발할 것이고,
SNS의 경우 사진 업로드, 댓글 업로드 및 공유 등을 위해 개발할 것입니다
이때 공학/기술적인 문제는 비즈니스와 분리되는데요,
여기에 해당하는 문제는 은행 사용자 데이터를 어떻게 저장할 것인가, 사진을 어떻게 빠르게 로딩할 것인가 등등이 있습니다
📎 비즈니스 로직 VS 어플리케이션 서비스 로직
비즈니스 로직과 어플리케이션 서비스 로직을 구분해보기 위해 코드가 하는 일을 크게 두가지로 나누어 보았는데요
1. 특정 문제 영역에 대한 솔루션을 제공하는 코드
ex) 동영상 촬영, 댓글 달기
2. 그 코드를 가능하게 만들고, 입력과 출력을 처리하기 위한 코드
ex) 데이터베이스에 연결, 백엔드 서버와 통신, 사용자 UI에 띄우기
이렇게 나눈 코드 중 1번은 현실 세상의 문제를 해결하는 코드로 비즈니스 로직에 해당하고,
2번은 공학/기술적인 문제에 속하므로 어플리케이션 서비스 로직에 해당합니다
위에서 가장 큰 구분 기준은 바로 이 코드가 현실 문제,
즉 비즈니스에 대한 의사결정을 하고 있는가? 입니다
📎 직접 로직을 분리해보자 !
모바일 송금 과정을 나열하고 이를 로직 분리를 해보도록 하겠습니다
1. 계좌 잔액이 충분한지 확인한다
2. 유효하다면 송금 버튼을 활성화하고, 유효하지 않다면 에러 메시지를 띄운다
3. 사용자의 멤버십 등급에 맞춰서 송금 수수료를 계산한다
4. 송금 수수료를 결제하도록 외부 결제 서비스에 요청한다
5. 사용자의 잔액을 감소시킨다
6. 사용자의 잔액을 DB에 저장한다
우선 비즈니스 로직을 분리해주기 위해서는 '송금'에 대한 의사 결정을 담당하고 있는가를 확인해 보아야 합니다
1. 계좌 잔액이 충분한지 확인한다
-> 송금이 가능한지에 대한 의사 결정
3. 사용자의 멤버십 등급에 맞춰서 송금 수수료를 계산한다
-> 송금에 드는 비용을 정책에 따라 결정
5. 사용자의 잔액을 감소시킨다
-> 송금이라는 서비스를 수행
송금에 대한 의사 결정을 담당하는 로직은 3개로 위의 로직들이 비즈니스 로직이 되고
어플리케이션 서비스 로직을 분리해주기 위해서는 의사결정을 할 수 있도록 입력을 제공하며, 결과를 외부 서비스/DB/UI에 업데이트를 해주는가를 확인해 보아야 합니다
2. 유효하다면 송금 버튼을 활성화하고, 유효하지 않다면 에러 메시지를 띄운다
-> UI 업데이트
4. 송금 수수료를 결제하도록 외부 결제 서비스에 요청한다
-> 외부 서비스와의 네트워킹
6. 사용자의 잔액을 DB에 저장한다
-> DB에 저장
이렇게 3개의 로직이 어플리케이션 서비스 로직에 해당하게 됩니다
🤔 만약 로직을 분리하는데 어디에 해당하는지 애매하다면?
해당 코드가 하는 일을 잘게 쪼개 봅시다 !
🍀 마무리
이렇게 구체적인 예시를 통해 직접 로직을 분리해보니 비즈니스 로직이 뭔지 정리가 되었고 UseCase도 더 정확하게 분리해서 사용할 수 있을 것 같더라구요 !
UseCase도 나누는 사람에 따라 조금씩 달라지겠지만 다른 기능에 영향을 주지 않도록 독립적으로 나눌 수 있도록 많은 코드를 살펴봐야 할 것 같습니다
프로젝트를 진행하고 코드를 수정할수록 점점 소프트웨어를 설계할 때 항상 등장하는 '결합도를 낮추기' 라는 것이 중요하다는 게 느껴지고, 결합도를 낮추기 위해서는 이런 비즈니스 로직을 잘 분리하고 설계하는 게 중요하다는 생각이 많이 들게 되는 것 같습니다
💡 참고
https://enterprisecraftsmanship.com/posts/what-is-domain-logic/
What is domain logic?
In this post, I’ll write about a couple of thoughts regarding what domain logic is and how to distinguish it from other types of logic.
enterprisecraftsmanship.com
'Android' 카테고리의 다른 글
[Android] 의존성 주입이란? (feat. 수동 의존성 주입) (0) | 2024.10.01 |
---|---|
구글 플레이스토어 첫 앱 출시기 <안뜰> (1) | 2024.09.20 |
[Android] 앱 배포하기04_ AAB 파일 만들기 (0) | 2024.09.04 |
[Android] 앱 배포하기03_ Proguard로 코드 난독화하기 (1) | 2024.09.02 |
[Android] 앱 배포하기02_ 안드로이드 스튜디오 Release build (0) | 2024.08.28 |