계층형 아키텍처(Layered Architecture) 잘(?) 사용하기

회사에서 개발하는 방식에 익숙해지다보면 점점 아키텍처를 바라보는 관점이 온전히 익숙한 방식을 따라 가게 되는 것 같아서 계층형 아키텍처에 대한 개인적인 생각을 한번 더 정리해보려고 한다.

 

Fat Service 지양하기

객체지향원칙을 따르며 계층형 아키텍처로 시스템을 구성할 때, 서비스가 복잡해지면 복잡해질수록 고민해야할 부분들이 많아진다. 

나는 보통 구성할 때 presentation, application, domain, infrastructure로 나누곤 하는데,

여기서 application(service) 과 domain 은 DDD 관점에서 도메인 레이어라고 볼 수 있다.

예를 들어, MemberService를 만들고 그 안에 회원가입, 이메일 변경, 휴면 계정 전환 등 member와 관련된 모든 서비스 로직을 넣게 되면 굉장히 서비스가 커지고 복잡해질 것이다.  MemberService 가 의존하는 다른 컴포넌트가 많아질 뿐더러 특정 로직을 사용하기 위해 거대한 MemberService를 주입받아야하는 다른 서비스도 많아질 것이다.

도메인 엔티티가 대부분의 비즈니스 로직 역할과 책임을 가져가게 되면 서비스 메서드 하나당 로직이 간단해지기 때문에 어느정도 대처가 가능하다. Service는 도메인에게 도메인 로직을 위임하는 역할과 트랜잭션 관리만 할 수 있다.

하지만 아직 하나의 서비스가 가져야할 역할과 책임이 크다고 느껴질 때가 있다. 이럴때 보통 명령과 조회를 나누어 XXCommandService, XXQueryService 로 나누거나 기능 하나에 대한 유스케이스별로 Service를 생성하기도 한다.

단순한 CRUD 라면 일단 하나의 서비스를 사용하는 것도 괜찮다고 생각한다. 다만 시스템 기능의 일부로서 큰 유스케이스를 담당한다면 분리하는 것이 이상적이다. 물론 모든 유스케이스에 대해 서비스를 전부 분리해서 만들수는 없기 때문에 분리 필요성을 느낄 시점에 분리해도 늦지 않다고 생각한다.

 

Facade 는 반드시 필요할까?

예전에 서비스가 서비스를 호출하면 안되는다는 생각을 가지고 있었다. 레이어간 역할이 명확하다고 생각했고 서비스가 타 서비스를 의존하게 될 때 참조 관계가 나중에 뒤섞여서 유지보수하기 힘들어지지 않을까 생각했던 것 같다. 그래서 이런 경우라면 Facade를 도입하는게 맞다고 생각했다.  

물론 순환 참조가 발생하지 않도록 경계하고 조심해야하는 것은 맞지만 최근에 드는 생각은 유스케이스 하나에 대해 중요한 로직은 전부 서비스에 있는게 맞고 하나의 서비스가 타 서비스를 참조해서 호출해도 된다고 생각한다. 유스케이스가 복잡하다면 역할과 책임에 따라 어떤 로직은 다른 서비스에 있을 것이고 그걸 묶어서 하나의 유스케이스가 되는 서비스가 존재할 것이다. 파사드는 유스케이스의 핵심 로직이 아닌 그 외 같은 트랜잭션으로 묶이면 안되는 부가 기능이 있을 때 사용하는 것이 좋은 것 같다.

 

변화에 대응하기 용이한, 유연한 구조를 가져가기

객체지향원칙을 고려해서 설계해야하는 이유가 무엇일까? 솔직히 어느 순간부터는 내가 왜 객체지향적인 설계를 지향하고 있는가에 대해 생각을 하지 않았다. 업무를 하다보면 요구사항이 빠르게 변화하기도 하고 어제 짠 코드가 오늘 레거시가 되기도 한다. 애자일 개발 선언에서도 이야기하듯이 계획에 따르기보다는 변화에 대응하는 것이 더 중요하다. 

변경과 확장에 용이한 설계를 위해서는 OCP, DIP 를 지키는 것이 중요하고 객체의 역할과 구현을 분리할 필요성이 있다.

인터페이스를 잘 설계하면 클라이언트의 변경 없이 확장에 용이한 구조가 된다. 앞으로 함께 코드를 디벨롭해나가야할 팀과 나를 위해 기초를 튼튼히 하는 것이다.

 

번외) 헥사고날 아키텍처

이전 회사에서는 헥사고날 아키텍처를 썼었고 현 회사에서는 계층형 아키텍처를 쓰고 있다. 둘 다 DDD를 기반으로 하고 있지만 JPA 를 쓰는 환경이라면 도메인 로직과 강하게 결합되어있기 때문에 도메인 엔티티와 영속성 엔티티를 분리하지 않는 이상 포트와 어댑터로 뺄만한 로직들이 많이 없다고 느꼈다. 

이전 회사에서는 WebFlux + R2dbc 를 사용했었던만큼 JPA와 같이 ORM 강결합이 없었어서 헥사고날 아키텍처를 도입했을 때의 장점이 명확했다. 도메인 엔티티를 별도로 분리하고 영속성, 외부 통신과 같은 로직을 포트라는 인터페이스로 분리해서 책임을 위임하였을 때 서비스 로직이 간단해지고 또 다른 구현체로 갈아끼우기도 용이했다.

기술과 구조 간 궁합도 중요한 것 같고 헥사고날을 도입했을 때 추상화, 도메인 변환 비용 등 트레이드 오프가 존재하기 때문에 주어진 환경에 따라 올바른 선택이 필요하다고 생각한다. (헥사고날이라고 해서 무조건 도메인 엔티티와 영속성 엔티티를 분리해야한다고 생각하지도 않는다.)