레이어드 아키텍처 vs 헥사고날 아키텍처

레이어드 아키텍처

목적

같은 목적의 코드들을 같은 계층으로 그룹화한 것, 역할과 관심사를 계층으로 분리

특징

• Presentation 계층은 Business 계층에 의존하고 Business 계층은 Persistence 계층에 의존
• 동시 작업성이 떨어진다(repository - service - controller 순으로 개발이 이루어짐)
• 결국 DB 주도 설계로 갈수밖에 없는 구조 --> 객체간의 협력, 책임, 행동, 상태를 먼저 고려하지 않고 DB부터 생각할수밖에 없는 구조
• 데이터베이스(DB)와 비즈니스 로직이 강하게 결합되는 단점이 존재합니다.
• 상향식 접근법, jpa 에 종속적인 (jpa -> service -> controller)
• 하향식 접근법, spring에 의존적인 (jpa <- service <- controller)
• 계층을 분리하는 규칙 외에는 다른 규칙을 강요하지 않기 때문에 도메인 로직이 여러 계층에 걸쳐 흩어지기 쉽다.(깨진 창문 이론) 사소한 무질서를 방치했다간 나중엔 지역 전체로 확산될 가능성이 높음
• 전혀 다른 업무 도메인의 코드 라도, 코드 들을 계층형 아키텍처에 따라 작성하는 경우 무조건 view, controller, model 이 3가지 패키지에만 들어가버리기 때문에 해당 서비스가 어떤 도메인으로 구성 되었는지를 파악하는것이 까다롭다는 문제점이 존재합니다.

도메인, 비즈니스라는 말은, '소프트웨어가 풀고자하는 현실 세상의 문제'를 가리킨다.

 

 

 

 

 

클린 아키텍처, DDD와 같은 것들이 등장하기 시작 -> 너무 추상적이기에 원칙들을 좀더 구체적으로 구현하는 헥사고날 아키텍처의 등장

헥사고날 아키텍처

헥사고날 아키텍처를 통해서 비즈니스 로직을 외부 세계로부터 격리시켜 유연하고 테스트하기 쉬운 구조를 만드는 것

 

 

 

 

 

 

 

 

레이어드 아키텍처와의 차이점

Ports 라는 추상화를 도입해서 의존성을 역전하는 것이 레이어드와 두 아키텍쳐의 가장 큰 차이점

 

 

장점

외부에서 도메인으로 향하는 방향이 단방향으로 유지(도메인이 순수해진다.)

소프트웨어는 도메인에 충실(애플리케이션의 핵심에 충실)

올바른 상향식 접근가능

상하 대칭으로 표현

 

 

 

단점

추상화 계층을 도입하면 의존성을 줄이거나 역전할 수 있지만 대부분 복잡도가 올라간다. 따라서 복잡도가 많이 필요하지 않은 작은 시스템에서는 레이어드에 비해 얻을 수 있는 장점이 크지 않을 수 있다.

 

 

 

 

참고코드

post
 ㄴcontroller
   ㄴPostController.java
   ㄴPostCreateController.java
   ㄴport
     ㄴPostService.java
   ㄴresponse
     ㄴPostResponse.java

 ㄴdomian
   ㄴPost.java
   ㄴPostCreate.java
   ㄴPostUpdate.java

 ㄴinfrastructure
   ㄴPostEntity.java
   ㄴPostJpaRepository.java
   ㄴPostJpaRepositoryImpl.java

 ㄴservice
   ㄴPostServiceImpl.java
   ㄴport
     ㄴPostRepository.java

user
...
...
common
...
...

https://github.com/newcodingtest/hexagonal-architecture

 

 

 

 

 

 

출처: https://www.inflearn.com/course/lecture?courseSlug=%EC%9E%90%EB%B0%94-%EC%8A%A4%ED%94%84%EB%A7%81-%EC%A3%BC%EB%8B%88%EC%96%B4-%EA%B0%9C%EB%B0%9C%EC%9E%90-%EC%98%A4%EB%8B%B5%EB%85%B8%ED%8A%B8&unitId=160125&tab=curriculum