오늘은 프로그래밍 용어 중 비즈니스 로직(Business Logic)에 대해 알아보겠다.
비즈니스 로직이란?
비슷하게 도메인 로직이라는 말이 있는데, 사실상 도메인 로직과 비즈니스 로직은 동의어라고 볼 수 있다.
소프트웨어 공학에서 도메인, 비즈니스라는 말은, '소프트웨어가 풀고자하는 현실 세상의 문제'를 가리킨다.
예시로, 은행 앱이라면, 금융 및 은행 업무가 도메인이다. 은행 앱이 해결하고자 하는 문제가 금융 업무를 스마트폰에서 처리할 수 있게 해주는 것이므로.
틱톡 같은 SNS라면 동영상 촬영, 감상, 댓글 및 공유일 것이다. SNS가 해결하고자 하는 문제는 우리가 공유하고자 하는 사진, 영상을 누구든 볼 수 있게 하는 것이므로.
반대로 공학/기술적인 문제에 속하는 것들은 대개 '도메인'과는 구별된다. 수많은 은행 사용자 데이터를 어떻게 효율적으로 저장할 것인가. 어떻게 고화질 동영상을 빠르게 로딩할 것인가? 등등.
모든 코드는 비즈니스 로직이 아닌가?
우리는 특정한 문제 영역에 대한 솔루션을 제공하는 코드 외에도 많은 코드를 써야한다.
그 코드를 가능하게 만들고, 입력과 출력을 처리하기 위한 로직들이다.
대표적으로 데이터베이스에 연결하고, 백엔드 서버와 통신하고, 사용자와 인터랙션하는 코드들이 필요하다.
이런 것들은 도메인 로직과 구분지어 어플리케이션 서비스 로직이라고 부른다.
간단히 말해 도메인 로직은, '현실 문제에 대한 의사결정을 하는 코드' 라고 볼 수 있다.
모바일 송금의 예시
예를 들어서, 흔한 모바일 송금 앱이 있다고 해보자.
송금 기능을 담당하는 코드가 있다.
이 코드를 자세히 뜯어보면 다음과 같은 일을 하는 코드로 이뤄져있다.
- 계좌 잔액이 충분한지 확인한다.
- 유효하다면 송금 버튼을 활성화하고, 유효하지 않다면 에러 메시지를 띄운다.
- 사용자의 멤버십 등급에 맞춰서 송금 수수료를 계산한다.
- 송금 수수료를 결제하도록 외부 결제 서비스에 요청한다.
- 사용자의 잔액을 감소시킨다.
- 사용자의 잔액을 DB에 저장한다.
이 코드들을 구분할 때, 해당 소프트웨어가 '송금'이라는 현실 문제에 대한 의사결정을 하는가를 생각해보자.
어떤 것이 도메인 로직이고, 어떤 것이 서비스 로직일까?
도메인 로직에 해당하는 것은 다음과 같다.
이 코드들은 '송금'에 대한 의사결정을 담당하고 있다.
1.계좌 잔액이 충분한지 확인 -> 송금이 가능한지에 대한 의사결정
2.송금 수수료를 계산 -> 송금에 드는 비용을 정책에 따라서 결정
3.사용자의 잔액을 감소시킨다 -> 송금이라는 서비스를 수행
어플리케이션 서비스 로직에 해당하는 것은 다음과 같다.
이 코드들은 도메인 로직이 의사결정을 할 수 있도록 입력을 제공하며, 결과를 외부 서비스/DB/UI에 업데이트하는 역할을 맡는다.
1.유효하지 않으면 에러 메시지를 띄운다 -> UI
2.송금 수수료를 결제하도록 외부 결제 서비스에 요청한다. -> 외부 서비스와의 네트워킹
3.잔액을 DB에 저장한다. -> Persistence(영속성)
만약 어떤 코드가 명확하게 도메인 로직인지 아닌지 애매하다면, 해당 코드가 하는 일을 쪼개야 한다는 신호다. 도메인 로직이 분명한 부분과 서비스 로직이 섞여 있을 수도 있다.
현재 가지고 있는 원화가 미국 달러로 얼마인지 보여주는 함수가 있다고 해보자.
이 함수 하나만 가지고 생각하면 도메인 로직인지 아닌지 애매하다.
하지만 함수를 분리하고 코드를 쪼개보면 좀 더 명확해진다.
- 미국 달러 환율을 얼마로 할 것인가. 계산 공식은 얼마로 할 것인지 결정하는 코드. -> 도메인 로직
- 단위와 화폐 포맷을 바꿔서 UI에 업데이트를 하는 코드. -> 어플리케이션 서비스 로직
영역 구분하기
홈페이지 회원가입으로 예를 들어보자.
유저는 회원가입 양식 폼에 회원정보를 작성하고, 회원가입 버튼을 누르면 회원가입이 진행된다.
이 과정 중 아이디 중복 검사, 본인 인증, 비밀번호 재 검사 등 유저가 통과해야 할 것이 많다.
유저는 단순한 버튼 클릭으로 아이디 중복인지 아닌지, 본인의 인증이 올바른지, 비밀번호 가 올바른지 등등을 홈페이지의 글이나, 다이얼로그로 확인한다.
유저 입장에선 아무렇지 않게 확인하고 있는 것 들이지만, 프로그래머는 위에 일련의 인증할 것들을
구현하기 위해서는 생각보다 많은 수고를 들인다. 프로그래머 입장에 서서, 영역을 나누어 보자.
위의 아이디 중복 검사를 예시로 들자면,
프로그래머는 유저가 입력한 아이디가 회원 중 아이디를 중복으로 쓰고 있는지 검사하기 위해
데이터베이스를 조사한다. 데이터베이스를 조사 후, 중복 아이디가 없다면 유저에게 페이지 속 글 또는 다이얼로그로 아이디를 사용해도 된다는 표시를 해준다.
여기서 크게 2영역으로 나눌 수 있다.
하나는 중복 아이디가 있는지 없는지를 검사하기위한 일련의 과정들 ( 1번째 영역 )
나머지는, 유저에게 단순히 텍스트나 다이얼로그로 알려주는 것이 있다. ( 2번째 영역 )
2번째 영역은 흔히, Presentation 영역 혹은 View 영역 이라고 많이 불리우는데,
가공된 데이터를 단순히 표시만 해주는 것이다. (ex 아이디가 중복됬습니다 표시, 비밀번호 재 검사를 실패 했습니다. 등등)
그 데이터 가공을 담당하는것이 1번째 영역 흔히들 Logic 영역, Model 영역이라 불린다.
비즈니스 로직이란?
위에서 소개한 영역 2가지 중, 첫번째 영역에서의 코딩을 흔히, 비즈니스 로직이라 부른다.
위의 아이디 중복찾기를 다시 예시로 들자면, 아래와 같은 비즈니스 로직이 작성될 것이다.
회원이 작성한 아이디 값 저장하기 -> 회원정보가 있는 데이터베이스 연결 ->
데이터베이스에 회원이 작성한 아이디 값이 있는지 Select -> 회원의 아이디가 이미 있는지 없는지 여부를 데이터화 하여 저장 -> 데이터베이스 연결 끊기 -> View영역에게 가공된 데이터 전달
이러한 비즈니스 로직은 유저 눈엔 보이진 않지만, 유저가 바라는 결과물을 올바르게 도출하기 위해 코드로 짜여진다.
즉, 프로그래머는 유저가 원하는 행위를 컴퓨터에게 잘 전달하기 위해서는 비즈니즈 로직을 잘 구상해야 한다는 의미이다.
이처럼, 비즈니스 로직은 프로그래밍에서 빠질 수 없는 요소이며, 응용 프로그램의 핵심이 된다.
비즈니스 로직은 유저가 바라는 결과물을 코드로 옮기므로 코드가 자주 변경되므로, 코드 품질 또한 매우 중요하다.
비즈니스 로직이 정리되지 않고 이곳 저곳 산재 배치되면, 프로그래머는 코드 관리에 어려움을 느끼고, 개발을 어렵게 하는 요인이 될 수 있는 것이다.
그리고 그로 인하여 생산성, 품질등이 저하 된다.
비즈니스 로직은 정말 중요하지만, 유지보수 와 확장성을 고려한 코딩을 하기란 쉽지 않다.
프로그래머들은, 조금 이라도 더 비즈니스 로직을 잘 작성하기 위해 프로그래밍 아키텍쳐를 공부를 해야하는 이유가 아닐까 싶다.
( 예를들어, 웹에서 주로 쓰이지만 대중적인 MVC, 안드로이드 에서 인기를 얻고 있는 MVP등등 )
reference
