• 원래는 Port & Adapter Pattern이라고 불림.

• User-side, Business logic, Server side를 분리

  

의존방향

• 유저도 비즈니스 로직에 의존
• 서버사이드도 비즈니스 로직에 의존
  • PoetryLibraryFileAdapter 로 인터페이스 구현.
    • 이후 비즈니스로직에서 IObtainPoems 인터페이스로 서버사이드와 통신하면 거기에서 PoetryLibraryFileAdapter 로 역할 수행하는 것.
    • ORM과 그 구현체의 관계라고 생각하면 편할 듯 하다.
• 즉, 둘 모두 비즈니스 로직을 파라미터, 멤버변수, 로컬변수,리턴 값등으로 참조한다.

Ports and Adapter

• Ports and Adapters 개념은 hexagonal architecture의 은유법(metaphor)다.

  • inside, outside간의 인터렉션을 표현하기 위해 사용함.

• 그림을 보자

  

  • 초록색은 Port(인터페이스)
    • Inside
  • 주황색은 Adapter(구현체)
    • Outside

Martin Powler - domain data layering

• 이렇게 애플리케이션을 모듈화하는 경우 집중해야할 범위를 줄여준다.
  • 일종의 SoC
• 이렇게 하면
  • Presentation 만들때는 UI만 고려하면됨
  • Domain layer에서는 받은 데이터를 도메인 로직에 따라 어떻게 업데이트할지만 생각하면 된다.
  • Data Access Layer에서는 데이터를 어떻게 다룰지만 생각하면 됨.
• 하지만 이렇게 각각의 layer를 나누는 것 만으로는 프로그래밍시의 관점을 제공하지 않는다.
  • layer간의 반복?(iterate)이 필요한 경우를 자주 보았음.
  • domain layer와 data layer를 UX에 대한 이해 없이 만들 수도 있겠지만, UX를 재정의하게 되면 domain을 바꿔야하고 이는 data layer를 변경하도록 만들게 된다. 하지만 cross-layer iteration이 있으면 이렇게 변해도 더 쉽게 layer를 변화시킬 수 있다.
    • 이유 : It's similar to the switching of thinking modes you get with refactoring's two hats
  • 모듈화는 모듈의 다른 구현체들로 대체가 가능하도록 해준다.
    • 위 분리는 동일한 도메인로직에서 여러개의 presentation을 생성할 수 있도록 한다.
      • 여러개의 presentation은 웹앱 내의 페이지를 나눌 것이다.
      • data source를 모듈화하면 database 기술을 바꾸더라도 편하게 이를 다룰 수 있게 되고, 영속성 관리를 편리하게 사용할 수 있도록 해준다.
  • Testability 증가.

More layer

• layer stack에 의해 보통 위에서 아래로 돌아감.
  • 기존에는
  • presentation은 domain에 의존
  • 기존에 domain은 data source에 의존