Business logic에 대한 생각

비즈니스 로직이란 어떤 서비스나 프로그램의 Core 한 부분을 이루는 중요한 요소중 하나이다.

모든 프로그램이나 서비스에는 추상적인 '개념'이나 '콘셉트'가 있다.
프로그램이나 서비스의 본질을 파고들다 보면, 결국에는 사전에 정의한 구조화된 데이터를 잘 컨트롤할 수 있느냐이다.
이러한 개념이나 콘셉트, 구조화된 데이터를 기반으로 비즈니스 로직이 작성된다.
그러하여 비즈니스 로직은 추상적인 개념이나 콘셉트를 실제 세계에 구현할 수 있는 것이며 개념과 콘셉트를 유지시킬 수 있는 것이다.

실제 비즈니스 로직은 개념과 콘셉트를 지키기 위한 규칙 위에서 작성되며 어떠한 Action이 수행될 때 여러 인터셉터들을 거치며 생성/수정/삭제 되는 데이터들의 유효성을 검증할 수 있다.
위와 같은 작업으로 인해 비즈니스 로직은 서비스나 프로그램의 중심 개념을 지킬 수 있다.

예를 들자면 A 객체의 keys는 ['name', 'use']가 있고,
B 객체의 keys는 ['id', 'value']가 있으며,
A 객체의 'use' key는 B 객체의 'id' key를 참조한다.

이 때 A 객체가 참조하고 있는 B 객체를 삭제하고자 한다면 A 객체가 참조하고 있는 B 객체가 사라지는 것이기 때문에 문맥이 맞지 않게 된다(개념과 콘셉트를 유지하지 못한다).

위와 같은 상황이 발생했을 때에는 프로그램이나 서비스의 개념과 콘셉트에 맞춰 여러가지 방안을 생각해볼 수 있다.
이 말은, A 객체가 참조하고있는 B 객체가 삭제됐을 때, 유연하게 생각하여서 A 객체의 참조 key인 'use' key를 null로 설정한 뒤, B 객체의 삭제 Action을 처리할 수도 있다.
아니면 A 객체의 참조 key인 'use' key를 삭제한 뒤, Flag를 세우는 방법을 고려할 수도 있다. 이 방법은 아마 플랫폼 서비스에 자주 활용될 듯 한데, 이렇게 의존 관계가 깨졌을 시 '사용자'가 해당 트랜젝션이 수행됐는 지를 알아야 하기 때문에 해당 flag를 통해 사용자에게 알려줄 수 있다.

위와 같은 방법이 아닌 Strict하게 생각한다면, A 객체가 참조하고 있는 B 객체의 삭제 Action을 실행하게 된다면 B 객체의 삭제 Action을 Reject 할 수도 있는 것이다.

위의 세 가지 예제는 모두 프로그램이나 서비스의 개념 혹은 콘셉트에 기반하여 기획할 수 있는 것이고, 이로써 글 도입부에 말했던 내용이 설명된다.