[도메인 주도 설계로 시작하는 마이크로서비스 개발] 비즈니스 로직은 어디에? 관심사의 분리

 

1) 관심사의 분리

- 소프트웨어의 핵심은 비즈니스 로직이라는 말을 많이 들어봤을 것이다.

  비즈니스 로직이란 보통 시스템의 목적인 비즈니스 영역의 업무 규칙(Rule), 흐름(Flow), 개념(Concept)을 

  표현하는 용어다.

 

- 개발자의 역할은 문제 영역의 비즈니스 로직을 분석 및 이해하고,

  프로그래밍 언어라는 도구로 잘 표현하는 일이다.

  여기서 잘 표현한다는 것은 기능이 잘 동작하는 것과 더불어 

  이해하기 쉽고 변경하기 쉬운 시스템을 만드는 것을 의미한다. 

 

- 설계 원칙 중 관심사의 분리(separation of concerns)라는 원칙이 있다. 

  이것은 시스템의 각 영역이 처리하는 관심사가 분리되어 잘 관리돼야 한다는 의미이고,

  이 원칙은 시스템을 이해하고 변경하기 쉽게 만들어 준다.

  이 원칙에 따라 각 영역은 고유 관심사에 의해 분리되고 집중돼야 한다. 

 

- 모듈화 및 계층화도 이 같은 원칙에 기인한다.

  특히 비즈니스를 표현하는 비즈니스 로직 영역과

  기술 문제를 처리하기 위한 기술 영역은 철저히 분리하는 것이 좋다.

 

- 이것은 비즈니스 로직이 기술보다는 오랫동안 지속되고 

  안정적이어야 할 애플리케이션의 핵심 영역이기에

  기술에 영향을 적게 받도록 설계하는 것을 강조한데서 기인한다. 

 

- 기술과 비즈니스 로직을 분리했을 때, 복잡성이 낮아지고 유지보수성도 높아진다.

  특히, 객체지향 분석설계(OOAD: Object Oriented Analysis and Design)에서는

  비즈니스 로직을 누가봐도 이해하기 쉽게구조화하는 객체 모델로 표현하는 것을 강조해 왔다. 

 

- 애플리케이션의 유지보수성이 높다는 의미는 특정 개인에 의존하기보다는

  어느 누구라도 손쉽게 애플리케이션을 이해하고 

  유지보수할 수 있음을 의미한다. 

 

- 유연하고 확장성 있는 MSA 시스템을 만들기 위해서는 

  앞에서 언급한 각 마이크로서비스의 관계들을 유연하게 만드는 

  MSA 외부 아키텍처 및 패턴오 즁요하지만 

  마이크로서비스의 내부 구조를 어떻게 유연하게 만들 것인지도 중요하다. 

 

 

2) 데이터베이스 중심 아키텍처의 문제점

 

- '데이터베이스 중심 아키텍처'란 특정 관계형 데이터베이스에 의존한 

  데이터 모델링을 수행한 다음 이 물리 테이블 모델을 중심에 두고,

  애플리케이션을 구현하기 위한 사고를 하는 방식이다. 

 

- 일반적으로 스프링 프레임워크를 활용한다면, 

  컨트롤러(Controller), 서비스(Service), DB I/O, DTO로 구성되고,

  데이터 처리는 SQL 매핑 프레임워크인 마이바티스(MyBatis)를 사용한다.

 

- 이러한 구조에서 일반적으로 비즈니스 로직은 서비스에 존재해야 한다고 말하지만,

  서비스에 존재하게 될 로직은 흐름 제어 로직밖에 없다.

  그 밖의 비즈니스 개념과 규칙들은 

  앞에서 언급한 사례처럼 테이블과 SQL 질의에 존재한다.

  DTO는 질의를 통해 가져오는 정보 묶음의 역할 밖에 할 수 없다. 

 

- 이 구조는 이후에 살펴볼 애플리케이션의 로직 구성 패턴 중 하나인

  트랜잭션 스크립트 구조와 비슷한데,

  간단한 처리 로직의 경우에는 편하지만 업무가 복잡해지면 

  점점 복잡성을 제어할 수 없게 된다는 단점이 있다. 

  또한 업무 개념이 특정 저장 기술인 관계형 데이터베이스 테이블로 

  표현되고 업무가 복잡해질수록 업무 규칙이 데이터 질의 언어인

  SQL과 섞여 표현된다. 

 

- 앞에서 비즈니스 민첩성을 위해서는 유연성과 확장성이 중요하다고 한 바 있다.

  예를 들어, 한 회사에서 비즈니스의 특정 기능을 위해 읽기에 최적화된

  NoSQL 저장소로 교체하기로 결정했다고 하자.

 

- 그런데 이러한 시스템 구조에서는 저장소를 변경하려고 해도 

  쉽게 변경할 수가 없다. 

  왜냐하면 저장 기술과 비즈니스 로직이 끈끈하게 붙어 있기 때문에

  저장소를 변경했을 때 모든 것을 다시 구현해야 한다고 개발팀이 판단했기 때문이다. 

 

- 또한 데이터베이스 중심 아키텍처의 성능 측면을 보면

  이 같은 구조에서는 대부분의 성능을 데이터베이스에 의존한다.

  서비스의 비즈니스 개념과 규칙이 대부분 데이터베이스에 표현되기 때문이며,

  애플리케이션에서는 별로 할 일이 없다. 

 

- 따라서 데이터가 늘어남에 따라 데이터베이스의 성능으 지속적으로 떨어지게 되고,

  이를 최적화할 방법으로 데이터베이스의 서버의 사양과 용량을 계속 증가시키고

  질의문 튜닝에 몰두할 수 밖에 없다. 

 

- 앞에서 클라우드 인프라를 사용할 때의 가장 큰 장점인 사용량에 유연하게 대응하는

  자동 스케일 아웃이 의미가 없어진다.

  정작 바쁜 것은 데이터베이스이기 때문에 애플리케이션을 아무리 스케일 아웃해봐야

  거둘 수 있는 효과가 미미하다. 

 

- 데이터베이스의 본질은 데이터 저장 처리이고 여기에 최적화돼 있다.

  SQL도 비즈니스 로직을 처리하기 위한 언어가 아니라 데이터 처리에 최적화된 언어다.

  스토리지가 비싸고 한정적인 인프라 상황에서 최적의 성능을 발휘하기 위해

  데이터베이스 중심의 아키텍처가 필요했던 시기가 있었다. 

 

- 그렇지만 클라우드 시대에는 필요한 만큼 인프라를 유연하게 이용할 수 있고,

  저장 기술 또한 선택지가 다양하다.

  이전처럼 웹과 관계형 데이터베이스만 고려해야 하는 상황도 아니다.

  웹, 모바일, 명령형 인터페이스, IoT 기기 등 여러 디바이스의 입출력을 지원해야 하고,

  관계형 데이터베이스, 메모리 데이터베이스, NoSQL, 메시지 큐까지 다양한 저장소와의

  연계가 필요하다. 

 

- 즉, 클라우드의 풍부한 자원 환경에서느 애플리케이션 자체의 성능보다는

  애플리케이션의 확장성과 유연함이 더 중요하다.

  따라서 앞에서 언급한 관심사의 분리 원칙에 따라 끈끈하게 결합돼 있던

  비즈니스 로직 처리와 데이터 처리를 철저히 분리하는 것이 반드시 필요하다.