4편. Micro Service 내부를 지탱하는 아키텍처 (Layered, Clean, Hexagonal)

Layerd, Clean, Hexagonal과 같이 Micro Service 내부에서 사용되는 아키텍처에 대해 얘기해보고,
마지막 부분에서는 Hexagonal Architecture에 대한 생각과 커스텀하게 사용했던 패키지 구조에 대해서도 얘기해보겠다.

비즈니스 로직은 왜 분리해야 할까?

우선, 비즈니스 로직은 Process Rule, Flow, Concept 세 가지를 표현하는 용어이다.

 

이러한, 비즈니스 로직을 개발자는 코드로 풀어내야 하고 유지보수하기 쉽게 만들어내야 한다. (유연성과 확장성을 고려)
애플리케이션에서 사용하는 추후에 변경될 수 있는 기술과 비즈니스 로직이 분리되어야 복잡성이 낮고 오랫동안 안정성 있게 유지보수할 수 있게 된다.

 

하지만, 내가 지금 참여하고 있는 프로젝트만 하더라도 POJO Plain 한 자바 객체를 지향하고 철저하게 관심사를 분리하는 것을 강조하는 Spring Framework의 철학을 고려하지 않은 채, 모든 비즈니스 로직이 SQL 문에 들어있는 경우가 많다.

제대로 비지니스 로직을 갖춘 Entity가 존재하지 않고, 서비스와 컨트롤러가 존재하기는 하나 그저 Flow를 제어하기 위한 구색만 갖추어 사용되고 있다.

 

문제

1. Java로 구현된 비즈니스 로직을 읽는 것과, SQL로 이루어진 비즈니스 로직이 담긴 쿼리를 읽는 것은 난이도가 확실히 차이가 난다.

2. 나중에 비지니스 Rule이 변경되어 변경하라는 요청이 내려오면 제대로 대응할 수 없다.. 그냥 없다.

3. RDB에서 읽기에 최적화된 NoSQL로 변경하려 할 때 변경할 수 없다. 

4.DB에 너무 많이 책임을 부여하게 되어 과부하로 인한 문제가 발생할 수 있다. 따라서, 아무리 애플리케이션을 스케일 아웃하더라도 DB가 바쁘면 의미가 없다.

 

 

여기까지만 말해도, 비즈니스 로직은 왜 분리해야 하는지 알게 된다.

 

 

Layered Architecture - 애플리케이션을 유연하게 설계하는 아키텍처 1

나는 학부생 때 진행했던 프로젝트에서 대부분 레이어드 아키텍처를 사용해 왔다.
하지만, 바로 아래 그림처럼 전통적인 레이어드 아키텍처를 사용하지는 않았고 조금 밑에 나올 DIP를 적용한 레이어드 아키텍처를 사용했었다.

레이어드 아키텍처란 Web, Domain, Persistence를 위한 계층으로 서비스를 분리하는 방식이다.
다르게는, Presentation, Business Logic, Data Access 계층으로 말할 수도 있다.

 

• Web 계층 : 화면과 데이터를 주고받으며 커뮤니케이션하는 계층
• Domain 계층 : 비즈니스 로직을 처리하고 Flow를 제어하는 계층
• Persistence 계층 : DB와 커뮤니케이션하며 데이터의 CRUD를 처리하는 계층

 

하지만, 레이어드 아키텍처에는 문제❗️가 있다.

하위계층이 무엇인가 추가되어 확장될 때, 닫혀있어야 할 상위 계층이 의존하고 있는 하위계층에 의해 영향을 받게 된다. 예를 들어, Persistence 계층이 변경되었을 때 Domain 계층이 변경되면 OCP 원칙을 위배하고 있는 것이다.

물론, Persistence 계층의 인터페이스의 구현체만 다른 구현체로 바꾸는 것으로는 Domain 계층에 영향이 없을 것이다. 
하지만, Domain 계층에서 의존하는 Persistence 계층의 인터페이스를 변경하는 경우라면 영향을 받을 수밖에 없는 것이다.

 

 

Web과 Persistence 계층은 저수준 영역이고,  Domain 계층은 핵심 영역인 고수준 영역으로 보호받아야 마땅하다. 다음으로는 해결 방법에 대해서 말해보겠다.

 

Layered Architecture의 OCP 위배 문제를 어떻게 해결할 수 있을까?

위 그림에서 보고 어느 정도 예상할 수 있을 것이다.

 

Persistence 계층에서 존재하던 인터페이스를 Domain 계층으로 옮기는 것이다. 이게 바로 DIP 의존성 역전 법칙을 적용한 것이다.

이렇게 되면, Repository 인터페이스가 Domain 계층에 있기 때문에, 오히려 Persistence 계층에서 Domain 계층에 의존하게 된다.
따라서, 저수준 계층에서의 변경이 고수준 계층으로 전이되지 않게 된다.

 

아래 사진은 이전에 진행했던 예약시스템 Repository Interface이고, DIP를 적용하여 domain 영역에 존재한다.

 

이번에는, Repository 구현체로 domain 영역과 분리된 persistence 영역에 존재한다. 

 

 

지금까지, SOLID에서 OCP와 DIP를 실제로 경험해 볼 수 있는 예시였다.

 

 

Clean Architecture - 애플리케이션을 유연하게 설계하는 아키텍처 2

그 유명한 로버튼 C. 마틴이 제안한 아키텍처이다.

 

여러 레이어가 겹쳐져 있는 방식으로, 중앙에서부터 엔티티, 유스케이스, 기타 외부(Controller, Gateway, Web, DB, External Interface) 계층으로 이루어져 있으며 외부에서 내부로만 의존성 방향이 흐르게 된다.

 

안에서부터 밖으로 각 계층에 대해 간단하게 설명하겠다.

 

 

Entity 계층 

가장 고수준의 영역으로, 레이어드 아키텍처와는 다르게 가장 내부에 고수준 영역이 존재한다.

 

중앙에는, 레이어드 아키텍처에서도 가장 중요하다고 했었던 서비스의 비즈니스 업무 규칙을 다루는 Entity 계층이 존재한다.
주변에 있는 Use Case 계층에서 접근하는 도메인 Entity들이 존재한다.

 

엔티티 계층은 가장 간단한 객체로 존재해야 하므로, ORM과 관련된 프레임워크나 기타 복잡한 것들과는 관련이 없어야 한다.

 

Use Case 계층

Entity 계층을 감싸고 있으며, 레이어드 아키텍처에서는 Service라고 불렀던 것들이다.
Use Case라고 부르는 이유는 SRP 원칙을 지키기 위해서 유스케이스별로 분리하기 위해서라고 한다.

 

해당 계층에서는 Entity 계층 내부의 서비스의 비즈니스 업무 규칙을 호출하며 애플리케이션에 특화된 업무 규칙을 표현한다.

 

 

기타 계층

Use Case 계층을 감싸고 있는 나머지 기타 계층을 의미한다.

Controller부터 Gateway, Web, 외부 Interface, DB와 관련된 것들이 존재한다.

 

해당 계층에서 Use Case 계층과의 관계를 DIP 의존 역전 법칙을 이용해서 플러그인처럼 유연하게 처리해야 한다.

 

 

이렇게까지만 말하면, 정확히 어떻게 구현해야 할지 모호할 것이다. 조금 더 일반적인 용어로 설명된 아키텍처인 Hexagonal Architecture를 다음으로 설명하겠다.

 

 

Hexagonal Architecture - 애플리케이션을 유연하게 설계하는 아키텍처 3

클린아키텍처에서 설명한 것들을 더 일반적인 용어로 설명한 아키텍처이다.

그림에서 유추할 수 있듯이, Port & Adapter 아키텍처라고도 부른다.

 

이 아키텍처는 비즈니스 로직을 처리하는 고수준 영역과, 인터페이스 처리를 담당하는 저수준의 외부 영역으로 나뉜다.

 

내부 영역에는 외부 영역과 연계되는 Input Port와 Output Port를 가지고 있으며,
외부 영역은 외부에서 들어오는 요청을 처리하는 Inbound Adapter와, 내부 영역에서 호출되어 외부와 연계되는 Outbound Adapter로 구성된다.

 

 

또한, 내부 영역에서는 Entity와 Use Case가 존재하고, 외부 영역과 연계하기 위한 Use Case Interface가 존재한다. Use Case가 이러한 Use Case Interface를 구현하는 것이다. 
추가적으로, 내부 영역에 있는 또 다른 인터페이스가 있다. DB 저장소와 관련된 처리를 하기 위한 Repository Interface이다. Repository Interface를 내부 영역에 정의함으로써, 외부 영역의 저장소 어댑터는 해당 Repository Interface를 각 저장소에 맞게 기술적으로 구현하면 된다.

클린아키텍처와 헥사고날 아키텍처는 아래와 같이 거의 동일한 목적을 가지고 있다.

• 관심사끼리 분리해서 응집성을 높이고 다른 것들끼리는 의존성을 낮춘다.
• 비즈니스 로직을 다루는 코어 영역을 기술로부터 분리한다.
• 고수준의 영역이 저수준의 영역에 의존하지 않게 해야 한다. 여기서, 고수준이란 높은 계층을 의미하는 것이 아닌 중요도를 의미한다.
• Web, DB, Message Queue 등 저수준의 영역은 변경이나 교체의 여지를 두어야 한다.
• 저수준 영역의 구현체가 고수준 영역에 있는 자신의 인터페이스에 의존하게 하여 DIP 의존 역전의 법칙을 적용시킨다.

 

 

 

아래는 내가 Hexagonal Architecture를 적용하며, 사용했던 Package 구조이다.

src.groupname
	ㄴ global
    	ㄴ config
        ㄴ util
        ㄴ error
        	ㄴ exception
            	ㄴ handler
    ㄴ Aggregate Name
    	ㄴ adapter
        	ㄴ in
            		ㄴ web
                		ㄴ dto
                	ㄴ consumer
            	ㄴ out
            		ㄴ persistence
                	ㄴ producer
        ㄴ domain
        ㄴ application
        	ㄴ port
            		ㄴ in
                		ㄴ dto
                	ㄴ out
                		ㄴ repository
            			ㄴ producer
        	ㄴ validator

헥사고날 아키텍처가 지향하는 바를 대부분 담고자 했고, DIP 원칙을 적용하기 위해 Service 계층인 application에서 Output Port에 repository 인터페이스를 다루고자 했다.

 

또한, 정확히 Hexagonal의 규칙을 따르고자 한다면, domain 계층에는 정확히 POJO Entity를 사용하고, Adapter의 Outbound Adapter 부분에서 JPA를 적용한 Entity를 추가적으로 정의해야 한다.

하지만, 이 부분은 개발자에게 비용이 많이 든다. JPA라는 ORM을 변경하는 일이 나에게는 현재 없다고 생각하고 괜한 곳에 비용을 많이 쓰고 싶지 않았다.

따라서, 나는 domain 코어 계층에서 정의한 JPA Entity를 애플리케이션의 Entity로 생각하고 정의했다.

 

물론, 헥사고날에서 말한 코어에서 기술과 연계되는 부분이 없어야 한다는 점을 나는 지키지 않았지만, 나는 이 방법이 나에게 현재 상황에 더 잘 맞다고 생각하고 여러 아키텍처의 좋은 부분을 뽑아서 나의  현재 상황에 맞는 아키텍처로 만들면 된다고 생각한다.

 

 

도메인 모델 패턴과 Aggregate - 내부영역을 구현하기 위한

도메인은 비즈니스 로직을 가지고 있지 않고 서비스가 도메인을 호출하면서 비지니스를 처리한다면 서비스의 코드만 길어지고 중복이 많아지며 객체지향의 장점을 살리지 못하게 된다.

 

따라서, 위와 같은 트랜잭션 스크립트 패턴은 지양하고 도메인 모델 패턴을 지향해야 한다.

 

도메인 모델 패턴은 도메인 객체가 state와 behavior 둘 다 가지고 있고, 각 비지니스 로직에 대한 책임을 수행하는 역할을 도메인 객체가 수행한다. 이렇게 유스케이스를 구현하기 위한 서비스의 행위를 도메인에게 일부분 위임할 수 있다.

   

따라서, 서비스의 책임이 줄어들고 도메인으로 책임이 분산되기에 서비스는 여러 비지니스 규칙을 가진 도메인을 이용하여 업무 규칙만 처리하면 된다.

여기서, DDD (Domain Deriven Design)의 Aggregate 패턴을 적용할 수 있다.

사실, 여러 프로젝트에서 DDD를 도입하기 위해 수많은 노력을 했으나 완벽하게 비지니스 규칙을 도메인 엔티티로 가져오는 것은 쉽지 않았다. 계속해서 도전하면서 방법을 찾기 위해 노력해야 할 것 같다.

 

도메인 모델을 잘 만들면 자칫하면 서비스로 분리되어 중복 코드가 발생할 수 있는 일을 해결하며 코드의 양을 줄임과 동시에 재사용성을 높일 수 있다.

 

또한, Aggregate 패턴을 사용하는 이유는 여러 1 대 N 관계의 객체들이 서로 연관되어 도메인이 커질 때 N 측의 클래스가 수정되고 1측에서 코드를 수정해야 하는 상황처럼 문제가 점점 꼬일 수 있기 때문이다.

 

Aggregate를 나누는 기준은 나는 라이프사이클을 같이 하는 Object와 Value Object를 하나로 묶는 것이라 생각한다.

 

또한, Aggregate에 대한 규칙 이 있다.

• 애그리거트는 Root만 참조해야 한다.
• 애그리거트 내의 Object에 직접 참조하지 말고 Root를 통해서 참조해야 하며, 수정할 때도 동일하다.
• 애그리거트 간의 참조가 발생할 때는 PK 참조를 한다.  PK 참조를 통해 어그리거트 간에 결합도가 느슨해진다.
• 서비스에서 하나의 트랜잭션으로는 하나의 애그리거트만 생성하고 수정해야 한다. 

 

 

조금만 더

위에서 언급한 레이어드, 클린, 헥사고날 아키텍처 모두 MSA에서만 사용되는 게 아닌 Monolithic 한 구조에서도 사용할 수 있는 아키텍처이다. 하지만, MSA에서 추구하는 유연성, 확장성을 이 아키텍처들을 이용해서 더욱 효과적으로 발생시킬 수 있다. 

 

하지만, "Micro Service라고 무조건 이러한 아키텍처를 사용해야 하냐?"라고 한다면 그건 아니라고 생각한다.

비즈니스 로직이 복잡한 애플리케이션이면 헥사고날 아키텍처나 클린 아키텍처의 구조를 사용하는 것이 좋다고 생각하고,
간단하거나 조회 기반의 애플리케이션이라면 다른 방식으로 구현해도 될 것이다.