로버트 C. 마틴은 클린아키텍처에서 소프트웨어의 가치는 행위 가치와 구조 가치로 나뉘고, 소프트웨어를 정말로 부드럽게 만드는 것은 구조가치라고 언급한 바 있다. 여기서 행위 가치는 소프트웨어의 기능을 말하며, 구조 가치는 소프트웨어 아키텍처를 말한다.
코드와 설계의 구조를 깔끔하게 만들려는 생각을 하지 않고 기능 구현만 목적으로 삼으면 소프트웨어가 엉망이 된 상황에 대치하는 데 더 많은 비용이 든다는 점을 강조했다.
비지니스 로직이란 보통 시스템의 목적인 비지니스 영역의 업무 규칙, 흐름, 개념을 표현하는 용어다. 개발자의 역할은 문제 영역의 비지니스 로직을 분석 및 이해하고 프로그래밍 언어라는 도구로 잘 표현하는 일이다. 여기서 잘 표현한다는 것은 기능이 잘 동작하는 것과 더불어 이해하기 쉽고 변경하기 쉬운 시스템을 만드는 것을 의미한다.
설계 원칙 중 관심사의 분리라는 원칙이 있다. 이것은 시스템의 각 영역이 처리하는 관심사가 분리되어 잘 관리돼야 한다는 의미이고, 이 원칙은 시스템을 이해하고 변경하기 쉽게 만들어 준다. 이 원칙에 따라서 각 영역은 고유 관심사에 의해 분리되고 집중돼야 한다.
모듈화 및 계층화도 이 같은 원칙에 기인한다. 특히 비지니스를 표현하는 비지니스 로직 영역과 기술 문제를 처리하기 위한 기술 영역은 철저히 분리하는 것이 좋다. 이것은 비지니스 로직이 기술보다 오랫동안 지속되고 안정적이어야할 애플리케이션의 핵심 영역이라 기술에 영향을 적게 받고록 설계 하는 것에 기인한다.
기술과 비지니스 로직을 분리했을 때 복잡성이 낮아지고 유지보수성도 높아진다. 특히 객체지향 분석설계에서는 비지니스 로직을 누가 봐도 쉽게 이해하게 구조화 하는 객체 모델로 표현할 것을 강조해왔다.
현장의 소스코드를 보면 관심사의 분리 원칙이나 비지니스 로직을 표현하는 개체 모델은 온데간데없고 모든 업무 로직이 데이터 질의 구문인 SQL문에 들어가있는 경우가 대부분이다. 비지니스 로직을 처리하는 자바 코드는 10줄 미만인데, 100 ~ 1000줄이 넘는 SQL 문 또는 프로시저로 시스템이 가득차 있다.
내가 경험한 프로젝트의 한 개발자는 이처럼 아주 복잡한 SQL 문을 오직 자신밖에 관리할 수 없다고 자랑스러워하고 특정 벤더 데이터베이스에 정통했으며 모든 로직을 압축해서 하나의 SQL에 작성하는 것을 최고라 여겼다.
코드의 가독성보다는 쿼리 성능을 위한 SQL 문의 최적화에 우선순위를 뒀다. 물론 이 프로그램은 본인이 가장 잘 이해하고 업무 성과도 높았으나 그의 부재일 때 아무도 소스코드를 이해할 수 없었고 따라서 변경할 수도 없었다.
결과적으로 팀의 업무 병목지점이 되었고, 비지니스 로직이 대부분 SQL에 몰려 있다 보니 지속적인 데이터베이스 성능 저하로 데이터베이스도 병목지점이 되고 말았다. 결국 이 시스템은 더는 변경하기 힘들어져 전면 재개발 하였다.
애플리케이션의 유지보수성이 높다는 의미는 특정 개인에 의존하지 않고 어느 누구라도 쉽게 이해하고 유지보수 할 수 있는 것을 말한다.
유연하고 확장 있는 MSA시스템을 만들기 위해서는 앞에서 언급한 각 마이크로서비스의 관계들을 유연하게 만드는 외부 아키텍처 및 패턴도 중요하지만 내부 구조를 어떻게 유연하게 만들 것인지도 중요하다.
데이터베이스 중심 아키텍처란 특정 관계형 데이터베이스에 의존한 데이터 모델링을 수행한 다음 이 물리 테이블 모델을 중심에 두고 애플리케이션을 구현하기 위한 사고를 하는 방식이다.
이러한 구조에서 일반적으로 비지니스 로직은 서비스에 존재해야 한다고 말하지만 서비스에 존재하게 될 로직은 흐름 제어 로직밖에 없다. 그 밖의 비지니스 개념과 규칙들은 앞에서 언급한 사례처럼 테이블과 SQL 질의에 존재한다. DTO는 질의를 통해 가져오는 정보 묶음의 역할 밖에 할 수 없다.
이 구조는 이후 살펴볼 애플리케이션 로직 구성 패턴 중 하나인 트랜잭션 스크립트 구조와 비슷한데, 간단한 처리 로직의 경우에는 편하지만 업무가 복잡해지면 점점 복잡성을 제어할 수 없게 된다는 단점이 있다.