-
시스템 아키텍처와 관련한 다양한 아이디어들
-
육각형 아키텍처Hexagonal Architecture
-
포트와 어댑터(Ports and Adapters)라고도 알려졌으며, 앨리스터 코오번(Alistair Cockburn)이 개발
-
스티브 프리먼(Steve Freeman)과 냇 프라이스(Nat Pryce)가 그들의 훌륭한 저서인 '테스트 주도 개발로 배우는 객체 지향 설계과 실천'에서 차용
-
-
DCIData, Context and Interaction
-
제임스 코플리언(James Coplien)과 트리그베 린스쿠주(Trygve Reenskaug)가 만듬
-
-
BCABoundary-Control-Entity (= ECB)
-
이바 야콥슨이 자진의 저서인 'Object Oriented Software Engineering’에서 소개
-
-
-
위 아키텍처들의 목표는 '관심사의 분리separation of concerns'로 모두 같음
-
소프트웨어를 계층으로 분리함으로써 관심사의 분리라는 목표를 달성하고자 함
-
-
위 아키텍처들은 모두 시스템이 다음과 같은 특징을 지니도록 만듬
-
프레임워크 독립성: 프레임워크의 존재 여부에 의존하지 않는다. 프레임워크는 도구로 사용할 수 있을 뿐, 프레임워크의 제약사항안으로 시스템을 욱여 넣도록 강제하지 않는다.
-
테스트 용이성: 비지니스 로직은 외부 요소(DB, Server 등) 없이도 테스트할 수 있다.
-
UI 독립성: UI 변경시 나머지 시스템 요소가 변경할 필요가 없어야 한다. 즉, 비지니스 로직을 변경하지 않은 채 웹 UI를 콘솔 UI로 대체할 수 있다.
-
데이터베이스 독립성: 비지니스 로직은 데이터베이스에 결합되지 않는다.
-
모든 외부 에이전시에 대한 독립성: 실제 비지니스 로직은 외부의 인터페이스에 대해 전혀 알지 못한다.
-
의존성 규칙
-
위 그림에서 보통 안으로 들어갈수록 고수준의 소프트웨어가 된다.
-
바깥쪽 원은 메커니즘, 안쪽 원은 정책이다.
-
위와 같은 아키텍처가 동작하도록 하는 가장 중요한 규칙은 의존성 규칙Dependency Rule 이다.
소스 코드 의존성은 반드시 안쪽으로, 고수준의 정책을 향해야 한다.
-
내부 원에 속한 요소는 외부의 원에 속한 어떤 것도 알지 못한다.
-
외부 원에 선언된 데이터 형식도 내부의 원에서 절대로 사용하면 안된다.
-
외부 원의 프레임워크가 생성한 것이라면 더더욱 사용해서는 안된다. 외부 원에 위치한 것이 내부원에 영향을 주지 않기를.
-