Business Rule, Business Logic, Logic

아키텍처에 대한 이야기가 나오면 위 단어들이 빠지지 않는다.

위 단어들이 무엇을 의미하고 왜 분리하여 알아야 하는지 알아본다.

Business Logic

비즈니스 로직은 말 그대로 비즈니스와 관계되어 있다.

'출금' 기능을 구현한다고 하면 다음 처럼 구현할 수 있을 것이다:

if (amount <= balance) {            // 잔고가 충분하면
    balance -= amount;              // 잔고 감소
    let sql = 'update...';          // 데이터베이스 잔고 업데이트 쿼리
    query(sql, balance);            // 쿼리 전송
} else {
    alert('not enough balance.');   // 충분하지 않으면 사용자에게 알림
}

기능을 동작시키기 위한 모든 코드가 비지니스 로직이 된다.

Logic

그럼 일반 로직은 무엇인가?

위 예시 코드에는 나타나지 않은 DB에 연결하거나, Server를 실행 시키는 등

시스템이 동작하기 위한 코드들이다. 따라서 비즈니스와 별개로 반드시 필요한 코드다.

Business Rule

비즈니스 로직이 구현에 가깝다면 비즈니스 룰은 말 그대로 원칙이다.

위 예시 코드에서 '잔고가 충분하면', '잔고 감소', '사용자에게 알림'과 같이 자연어로 표현 가능하다.

클라이언트가 제시한 비즈니스 규칙을 개발자가 비즈니스 로직으로 구현할 수 있다.

비즈니스 로직이 비즈니스 룰을 설명 할 수도 있다.

비즈니스 규칙과 비즈니스 로직을 왜 분리하여 알아야 할까? (feat. Clean Architecture)

아키텍처를 설계하면 유지보수의 문제에 직면하게 된다. 좋은 아키텍처는 좋은 유지보수성을 나타낸다.

어느날 클라이언트가 '잔고가 없어도 사용자에게 알리지 않게 해주세요.'라고 말했다 치자. 문제는

비즈니스 룰과 관련된 코드: '잔고가 충분하면', '잔고 감소', '사용자에게 알림'

그렇지 않은 코드: '데이터베이스 잔고 업데이트 쿼리', '쿼리 전송'

위 코드들이 서로 섞여 있어서 가독성이 그렇게 좋지 않다는 것이다. 따라서 어떤 코드를 변경해야 사용자에 대한 알림이 가지 않는지, 그리고 해당 코드는 몇 줄에 걸쳐 나타나는지 분석해야 한다. 쿼리 수정을 할 때도 이런 문제는 발생한다.

Clean Architecture는 비즈니스를 규칙을 명시적으로 작성하고 비즈니스 로직과 계층을 분리하고, 비즈니스 로직을 작게 만들도록 한다.

계층을 분리함으로써 의존성을 분리하여 테스트하기 쉽게 한다. 잘 분리된 코드는 분석하기도 쉽다.