기타 옵션 헥사고날 아키텍처

지난번은 DI를 사용하여 레이어 아키텍처를 완전히 다른 레이어에서 모델을 분리하는 방법을 배웠습니다.

레이어와는 다른 생각으로, 레이어가 아니라 외부(뷰나 데이터베이스 액세스)와 내부(모델)가 있을 뿐이라는 생각이 있다고 합니다.

AlistairCokburn의 헥사고날 아키텍처는 그 아이디어 중 하나입니다.



뷰나 데이터베이스 액세스 등 각각이 각각의 어댑터를 가지고 있어, 각 어댑터가 어플리케이션의 내부에 맞춘 형식으로 변환합니다.

육각형의 각 변은 포트를 나타내며 입력 또는 출력에 해당합니다.
각 변의 포트의 정의는 엄밀하지 않고, 어느 한 변은 영속화를 담당, 어느 한 변은 뷰로부터의 입력을 담당, 또 어느 한 변은 메시징에 의한 통지를 담당 등. . .

이 헥사고날 아키텍처는 최근에 만들어진 개념이 아니고, 2004년의 PoEAA 책에 기재되어 있었고, 2002년경에는 이미 Wiki에서 소개되고 있었다고 합니다. ( 헥소고날 아키텍처의 일본어 번역 부터)

PoEAA의 소개에서는, 헥소고날 아키텍처를 채용하는 동기로서,

레이어 아키텍처에서는 사용자를 중심으로 생각해 왔지만 실제로는 다른 배치 처리이거나 웹 서비스 등 인간을 개입하지 않을 수도 있습니다. 그렇게 보면 프레젠테이션 레이어와 데이터 소스 레이어(인프라)에는 외부와의 연결에 관한 레이어로서 많은 유사점이 있는 것처럼 보입니다.

라고 말합니다.

특히, 현재는 비동기 메시징이나 Rest 등 외부와 접촉하는 기술이 늘어나고 있으므로, 이 사고방식은 합리적인 것으로 보입니다.

구현

포트가 어댑터가되어 구현하는 방법은 어떻게합니까? 라고 하는 의문이 솟아난다고 생각합니다만, 아마 지난번 라고 그렇게 변하지 않습니다.

어댑터는 MVC의 컨트롤러가 되어, 인프라의 Repository 구현이라도 OK라고 생각합니다. 포트는 뷰라면 Spring등의 프레임워크의 구조를 그대로 이용할 수 있고, DB와의 접속용도 Mybatis등의 구조를 사용할 수 있습니다.

파울러의 생각

헥소고날 아키텍처는 대칭 아키텍처이며 레이어 아키텍처는 비대칭 아키텍처로 간주됩니다.

그러나 나는 이 비대칭이야말로 유용하다고 생각한다. 다른 서비스로 제공하는 인터페이스와 다른 서비스를 이용하는 것 사이에는 역연한 차이가 있기 때문이다. 프레젠테이션은 다른 사람에게 시스템이 제공하는 서비스의 외부 인터페이스입니다. ... 데이터 소스는 서비스를 제공하는 것에 대한 인터페이스입니다. 클라이언트가 다르면 서비스의 사고 방식이 바뀌기 때문에, 이들을 나누어 생각하는 것이 유용하다고 나는 생각한다. ( PoEAA 제일 부분 레이어화 에서)

자신도 어느 쪽인가라고 하면, 이 생각에 찬성입니다. 하지만 외부와의 연결 기술은 늘어나고 정리하기 어려워지고 있습니다. 좀 더 아키텍처에 대해 생각하고 싶습니다.

단, 어떤 아키텍처도 모델을 분리하는 것이 가장 중요합니다.