-
육각형 아키텍처Hexagonal Architecture = 포트와 어댑터Ports and Adapters 패턴
-
육각형 아키텍처
-
비즈니스 관심사를 다루는 내부(inside)와 기술적입 관심사를 다루는 외부(outside)로 분해
-
외부에 포함된 기술적인 컴포넌트를 어댑터(adpater)
-
어댑터가 내부와 상호작용하는 접점을 포트(port)
-
계층형 아키텍처의 문제는 무엇일까?
-
계층형 아키텍처는 코드에 나쁜 습관드링 스며들기 쉽게 만듦
-
시간이 지날수록 소프트웨어를 변경하기 어렵게 만드는 수많은 허점들을 노출
-
데이터베이스 주도 설계를 유도함
-
책임이 계속 아래로 내려가고
-
데이터베이스에 비즈니스가 들어감 → 다양한 케이스를 지원해야하므로 동적 쿼리가 늘어남
-
-
데이터베이스 구조를 먼저 생각하고 도메인 로직을 구현했던 관습적인 방식을 벗어나야 함
-
도메인 로직을 먼저 만들고, 이것이 제대로 이해했는지 확인하고, 이를 기반으로 영속성 계층과 웹 계층을 만들어야 함
-
-
데이터베이스 중심적인 아키텍처가 만들어지는 가장 큰 원인은 ORM(obejct-relational mapping) 프레임워크를 사용하기 때문
-
비즈니스 규칙을 영속성 관점과 섞고 싶은 유혹을 쉽게 받음 → 강결합을 만듦
-
-
계층형 아키텍처의 유일한 규칙은 같은 계층 혹은 아래의 계층에만 접근 가능하다는 것
-
테스트하기 어려워 짐
-
엔티티 변경이 필요할 경우 도메인 계층을 변경하지 않기 위헤 웹 계층에서 계층을 뛰어넘어 엔티티를 바로 사용
-
도메인 로직이 웹 계층에 구현하게 됨
-
웹 계층에서 영속성 계층에 대해서도 mocking이 필요해짐
-
단위 테스트의 복잡도가 올라감
-
mock을 만드는게 많은 시간이 걸리게 됨
-
-
-
유스케이스를 숨김
-
도메인 계층이 여러 계층에 걸쳐 흩어지기 쉬움
-
유스케이스가 간단해서 도메인 계층을 생략한다면 웹 계층에 존재하게 됨
-
정리가 안되면 점차 새로운 기능을 추가할 적당한 위치를 찾는 일은 이미 어려워진 상태
-
계층형 아키텍처는 도메인 서비스의 '너비’에 관한 규칙을 강제하지 않음 → 아주 넓은 서비스가 만들어지기도 함
-
넓은 서비스는 영속성 계층에 많은 의존성을 가지게 됨
-
비지니스, 서비스 객체의 비대화가 시작됨
-
많은 컨트롤러가 해당 서비스를 참조하고, 서비스 내부에는 많은 레파지토리를 참조함
-
-
협업이 어려워짐
-
계층별로 나눠서 일하기 어려움
-
-
계층형 아키텍처는 많은 것들이 잘못된 방향으로 흘러가도록 용인함
-
아주 엄격한 자기 훈련 없이는 시간이 지날수록 품질이 저하되고 유지보수하기 어려워짐
-
의존성 역전하기
코드 구성하기
유스케이스 구현하기
웹 어댑터 구현하기
영속성 어댑터 구현하기
아키텍처 요소 테스트하기
경계 간 매핑하기
-
No-Mapping strategy
-
Two-Way strategy
-
Full strategy
-
One-Way strategy