
Application Architecture에서 가장 많이 활용되는 대표적인 패턴이다. 설계자들이 복잡한 시스템을 분리할 때 흔히 사용하는 패턴 중 하나로 상위는 하위를 호출하며, 하위의 여러 Layer를 알 필요 없이 바로 밑에 근접한 Layer를 활용하여 다양한 서비스를 이용한다. 따라서 개발 효율성이 높아지고, 어플리케이션이 쉽게 변경되거나 확장할 수 있다는 장점이 있다.
구성요소: 컨트롤러
화면 표현에 대한 처리(화면 전환 버튼 눌렀을 때 이벤트 처리, 세션 관리 기능)를 제공한다. 이 계층에서는 MVC 패턴이 가장 많이 쓰인다.
최근에는 웹, 모바일, 태블릿 등 다양한 인터페이스의 등장으로 지원을 위한 다양한 화면 플랫폼(thymeleaf, React, Vue.js)이 등장하였다. 따라서 다양한 기술을 정의하고 요구사항에 따라 고려하여 선택해야한다.
마이크로서비스의 성격에 따라 Fron-End 마이크로 서비스와 Back-End Biz 마이크로 서비스로 구분되기도 하며, Front-End 마이크로 서비스 측에서도 Presentation Layer가 존재하기도 한다. 이 두개의 마이크로 서비스는 각 클라우드에서 배포되어 Rest API를 통해 연계되어 서비스를 제공하게 된다.
그러나 Front-End 마이크로 서비스는 한 덩이기 때문에 모노리스 시스템의 단점들이 나타나, 최근에는 독립적으로 분해되어 서비스를 제공할 수 있는 방식, Server-side Page Fragment Compositon 방식이 등장했다.
구성요소: 서비스, 도메인
서비스: Presentation의 컨트롤러에서 호출되며 특정 업무의 처리 흐름을 제어한다.
도메인:주요 개념 및 구체적 로직을 담고 있다.
개발 운영 시 기능 추가와 변경은 로직 변경을 통해 이루어지기 때문에, 비지니스 민첩성을 좌우할 핵심 Layer이다. 따라서 이 Layer을 잘 구조화하고 설계하는게 중요하다.
Transaction 단위로 서비스 계층이 모든 처리 흐름을 혼자 처리한다. 도메인은 행위가 없고 데이터 처리 결과를 담는 홀더 역할 수행하거나, 결과를 담는 DTO의 역할 수행한다. 초급자도 쉽게 이해할 수 있는 장점이 있다.
서비스가 모든 Biz 흐름을 처리하지 않고 도메인 클래스의 Biz 개념에 따라 처리를 위임한다. 따라서 도메인은 객체 모델의 형태를 띄고, 서비스는 여러개의 도메인 모델 결과를 모아 로직 처리하는 경우에만 활용하게 된다.
처음에는 익숙해지기 어렵지만 복잡한 로직을 잘 조직된 방법으로 각 객체 모델에 위임하기 때문에 로직 중복들을 제거하고 잘 모듈화시킬 수 있는 장점이 있다.
또한 Business Logic 층에서는 고려해야할 사항이 몇가지 더 있다.
구성 요소: DAO(Data Access Object)
서비스가 처리한 결과를 받아 데이터로 저장하는 역할을 수행한다.
Business Logic 층의 영향을 적게 받는 것이 중요하여, 데이터 처리 매커니즘 검토가 필요하다.
Spring, Spring JPA, 하이버네이트 기술에 활용된다. 저장소를 고려하지 않고 Business Logic층에 필요한 Object가 무엇인지 먼저 고려한다.
Business Logic 층에서 Doain Model 패턴을 사용했을 때 유용한 매커니즘이다. 또한 저장소를 다른 관계형 데이터베이스 또는 NO-SQL 저장소로 쉽게 변경하는 경우 유용한다.
Mybatis 프레임 워크를 활용한다. 데이터 모델링을 통해 관계형 테이블을 먼저 작성 한 후, Business Logic 처리할 때 유용하다. Business Logic 층에서 Transacntion Script 패턴을 적용했을 경우 적합하며, 세밀한 SQL 컨트롤이 필요한 경우 유용하다.