육각형 아키텍처(Hexagonal architecture)

개인적인 공부 및 추후 다시 볼 수 있도록 하기 위해 개인 블로그에 번역 내용을 옮겨 놓았습니다.
원문과 내용이 다를시 책임지지 않으며, 저작권 문제가 발생시 언제든 삭제 될 수 있습니다. 

원문보기 : http://alistair.cockburn.us/Hexagonal+architecture

육각형 아키텍처(Hexagonal architecture)

UI 또는 데이터베이스없이 작동하도록 응용프로그램을 작성하여 응용프로그램에 대해 자동 회귀 테스트를 실행할 수 있습니다. 데이터베이스를 사용할 수 없어도 작동하며, 사용자의 개입 없이도 응용프로그램들을 연결할 수 있습니다.

---

(http://blog.tai2.net/hexagonal_architexture.html에서 이 기사의 일본어 번역을 볼 수 있습니다.) (Arthur Mauricio Delgadillo의 호의로 http://academyfor.us/posts/arquitectura-hexagonal 에서 이 기사의 스페인어 번역을 볼 수 있습니다.) (원래 설명 w는 http://wiki.c2.com/?HexagonalArchitecture 및 http://wiki.c2.com/?PortsAndaptersArchite에서 업데이트됩니다.)

육각형 아키텍처 FAQ 를 보세요.

---

 

패턴 : 포트와 어댑터 ( '객체 구조')

대체 이름 : "Ports & Adapters"

대체 이름 : ''Hexagonal Architecture''

 

의도

응용 프로그램을 사용자, 프로그램, 자동화된 테스트 또는 배치 스크립트에 의해 동일하게 구동할 수 있도록 합니다. 그리고 실제 런타임 장치 및 데이터베이스로 부터 분리하여 개발 및 테스트를 할 수 있도록 합니다.

이벤트가 외부 세계에서 포트에 도착하면 특정 기술의 어댑터가 사용 가능한 프로시저를 호출하거나 메시지로 변환하여 응용 프로그램에 전달합니다. 응용 프로그램이 입력 장치의 정체를 모르게 되어 기쁩니다. 응용 프로그램에 보낼 것이 있으면 포트를 통해 어댑터로 보내며 수신 기술(사람 또는 자동화 된 무언가)이 필요로 하는 적절한 신호를 생성합니다. 응용 프로그램은 어댑터의 반대쪽에 있는 사물의 본질을 실제로 알지 못하고, 모든면의 어댑터와 의미론적 상호 작용을 합니다.

Figure 1 : Hexagonal architecture basic.gif

 

동기부여

몇년간 소프트웨어 응용 프로그램에서 가장 무서운 것 중 하나는 비즈니스 로직을 사용자 인터페이스 코드에 작성하는 것입니다. 이것은 세 가지 문제를 일으킵니다.

• 첫째, 테스트 해야 하는 로직의 일부는 필드 크기 및 버튼 배치와 같이 변경되는 시각적 세부 사항에 따라 다르므로 자동화된 Test Suite 로 시스템을 깔끔하게 테스트 할 수 없습니다.
• 정확히 같은 이유로, 인간 중심의 시스템 사용에서 배치 실행 시스템으로 전환하는 것은 불가능합니다.
• 같은 이유로, 다른 프로그램에 의한 응용 프로그램의 구동을 허용하기 어렵거나 불가능합니다.

이를 해결하기 위해 많은 조직에서 시도한 방법은 아키텍처에 새로운 계층을 만드는 것입니다. 이제는 비즈니스 로직을 새로운 계층에 적용하지 않을 것 모두 약속 합니다. 그러나 약속 위반이 언제 발생하는지 감지할 수 있는 메커니즘이 없기 때문에 새로운 계층이 비즈니스 논리가 추가된 것을 몇년 후 확인하게되고, 이전과 동일한 문제가 다시 나타났음을 깨닫습니다.

응용 프로그램이 제공하는 ‘모든’ 기능중 일부를 API(Application Programmed Interface)나 함수 호출을 통해 이용 가능하다고 상상해 봅시다. 이 경우 테스트 또는 QA 부서는 응용 프로그램에 대해 자동화된 테스트 스크립트를 실행하여 새로한 코딩이 이전에 작성한 기능을 중단하는 것을 감지할 수 있습니다. 비즈니스 전문가들은 GUI 세부 사항이 완료되기 전에 프로그래머가 작업을 올바르게 수행 하였는지 알려주는 자동화된 테스트 케이스(테스트 부서에서 실행하는 테스트 스크립트가 됩니다)를 만들 수 있습니다. 응용 프로그램을 'headless'모드¹로 배포할 수 있으므로 API를 통해 다른 프로그램에서 기능을 사용 할 수 있습니다. 이는 복잡한 응용 프로그램의 전반적인 설계를 단순화하고 B2B 서비스 응용 프로그램이 서로 사용할 수 있게 합니다. 마지막으로 자동화된 함수 회귀 검사에서는 비즈니스 로직을 프리젠테이션 계층에서 제외하겠다는 약속 위반을 감지할 수 있습니다. 개발 조직은 비즈니스 로직이 추가된 계층을 수정할 수 있습니다.

응용 프로그램의 로직이 외부 데이터베이스 또는 다른 서비스에 연결된 경우 "반대방향"으로 유사한 문제가 있습니다. 데이터베이스 서버가 다운되거나 중요한 재 작업 또는 교체를 겪을 때 프로그래머는 데이터베이스의 존재에 묶여 있기 때문에 작업을 할 수 없습니다. 이것은 지연 비용과 종종 사람들 사이의 나쁜 감정을 야기합니다.

두 문제가 관련이 있는 것은 아니지만, 해결책의 본질에서 보면 대칭입니다.

 

옳바른 해결책

사용자측과 서버측 사이의 문제는 실제로 비즈니스 로직과 외부 엔티티와의 상호 작용 사이의 얽힘과 같은 설계 및 프로그래밍 오류로 인해 발생합니다. 이용할 비대칭성은 응용 프로그램의 '왼쪽'과 '오른쪽'이 아니라 '내부'와 '외부' 사이의 비대칭성입니다. 따라야 할 규칙은 '내부'의 코드가 '외부'로 나오면 안된다는 것입니다.

좌우 또는 상하 비대칭에서 잠시 떨어져 응용 프로그램이 외부 기관에 '포트'를 통해 통신하는 것을 보겠습니다. "포트"라는 단어는 프로토콜을 준수하는 모든 장치를 연결할 수 있는 운영 체제의 '포트'와, 전자 장치에 기계적이고, 전기적인 프로토콜에 적합한 장치가 연결되는 '포트'에서 따왔습니다.

• 포트 프로토콜은 두 장치 간의 대화를 목적으로 합니다.

프로토콜은 응용 프로그램 인터페이스(API)의 형태를 취합니다.

각 외부 장치에는 API 정의를 해당 장치에 필요한 신호로 변환하는 '어댑터'가 있으며, 그 반대의 경우도 마찬가지 입니다. 그래픽 사용자 인터페이스(GUI)는 사람의 움직임을 포트의 API에 매핑하는 어댑터의 예입니다. 동일한 포트에 맞는 다른 어댑터는 FIT² 또는 Fitnesse와 같은 자동화된 테스트 하네스 배치 드라이버 및 기업과 네트워크 전반에 걸친 애플리케이션 간의 통신에 필요한 코드입니다.

응용 프로그램은 외부 엔티티와 통신하여 데이터를 가져옵니다. 프로토콜은 일반적으로 데이터베이스 프로토콜입니다. 응용 프로그램의 관점에서, 데이터베이스가 SQL 데이터베이스에서 플랫 파일 또는 "모의"데이터베이스로 이동해도 API를 통한 대화가 변경 되어서는 안됩니다. 따라서 동일한 포트에 대한 추가 어댑터는 SQL 어댑터, 플랫 파일 어댑터와, 가장 중요한 "모의"데이터베이스에 대한 어댑터가 포함됩니다.이 어댑터는 메모리에 있으며 실제 데이터베이스의 존재에 전혀 의존하지 않습니다.

대부분의 응용 프로그램은 사용자측과 데이터베이스측의 두 포트만 있습니다. 이것은 비대칭적인 모습으로 1 차원, 3, 4 계층(Layer) 또는 5 계층의 스택 아키텍처로 응용 프로그램을 구축하는 것이 자연스럽게 보이도록 합니다.

이 방식에는 두 가지 문제가 있습니다.

• 첫째, 최악의 경우, 사람들은 도면의 ‘선’을 진지하게 받아들이지 않는 경향이 있습니다. 그들은 계층 경계를 가로 질러 응용 프로그램의 로직이 추가하여 위에서 언급한 문제를 일으킵니다.
• 둘째, 응용 프로그램에는 두 개 이상의 포트가 있을 수 있으므로 아키텍처가 1 차원 도면에 맞지 않습니다.

육각형 또는 포트와 어댑터 아키텍처는 상황의 대칭에 주목해서 이러한 문제를 해결합니다. 내부에는 여러 포트를 통해 외부와 통신하는 응용 프로그램이 있습니다. 응용 프로그램 외부의 항목은 대칭으로 처리할 수 있습니다.

육각형은 시각적으로 강조 표시하기 위한 것입니다.

• 내부 외부의 비대칭성 및 포트의 유사한 특성(1 차원의 도면과 그것을 상기시키는 것으로 부터 분리)과,
• 2, 3, 4의 서로 다른 포트의 수를 정의합니다 (4 개는 지금까지 내가 만난 것 중 가장 많습니다).

육각형은 6이라는 숫자가 중요하기 때문에 육각형인 것이 아니라, 1 차원 계층화 된 도면으로 제한하지 않고, 도면을 작성하는 사람들이 필요에 따라 포트와 어댑터를 삽입 할 수있는 공간을 가질 수 있도록 허용하기 때문에 육각형입니다. ‘육각형 아키텍처’라는 용어는 시각적 효과에서 유래했습니다.

‘포트와 어댑터’라는 용어는 도면 부분의 ‘목적’을 강조합니다. 포트는 의도적인 대화를 식별합니다. 일반적으로 해당 포트에 연결할 수 있는 다양한 기술에 따라 여러 개의 어댑터가 있을 것입니다. 일반적으로 전화 응답기, 사람의 음성, 터치 톤 전화기, 그래픽 휴먼 인터페이스, 테스트 장치, 배치 드라이버, http 인터페이스, 직접 프로그램 간 인터페이스, 모의 (in memory) 데이터베이스, 실제 데이터베이스 (아마도 개발, 테스트 및 실제 사용을위한 다른 데이터베이스) 가 포함됩니다.

응용 프로그램 노트에서 좌-우 비대칭이 다시 발생합니다. 그러나 이 패턴의 주된 목적은 모든 외부 항목이 응용 프로그램의 관점에서 동일하다는 것을 가정하면서 내부 외부 비대칭에 초점을 맞추는 것입니다.

 

구조

Figure 2 : Hexagonal architecture with adapters.gif

Figure 2는 각 포트에 대해 두 개의 활성 포트와 여러 개의 어댑터를 갖는 응용 프로그램을 보여줍니다. 두개의 포트는 응용 프로그램 제어 측면과 데이터 검색 측면입니다. 이 도면은 응용 프로그램이 자동화된 시스템 수준의 회귀 테스트를 통해 제품군, 사용자, 원격 http 응용 프로그램 또는 다른 로컬 응용 프로그램에 의해 동등하게 구동 될 수 있음을 보여줍니다. 데이터 측면에서 응용 프로그램은 '모의'데이터베이스를 사용하여 오라클 등의 외부 데이터베이스와 분리하여 실행하도록 구성할 수 있습니다. 응용 프로그램의 기능 사양은 내부(어쩌면 유스케이스내부)의 육각형 인터페이스에 대해 만드는 것이며 사용될지도 모를 외부의 기술에 대한 것이 아닙니다.

 

Figure 3 : Hexagonal architecture barn door image.gif

Figure 3은 동일한 응용프로그램을 3계층 도면으로 보여줍니다. 도면을 단순화 하기 위해 각 포트마다 두 개의 어댑터만 표시됩니다. 이 도면은 여러 어댑터가 상단 및 하단 레이어에 어떻게 붙는지와 시스템 개발 중에 다양한 어댑터가 사용되는 순서를 보여줍니다. 번호가 매겨진 화살표는 팀이 응용 프로그램을 개발하고 사용할 수 있는 순서를 보여줍니다.

1. 응용 프로그램을 구동하고 실제 데이터베이스를 대체하는 모의 (메모리 내) 데이터베이스를 사용하는 FIT 테스트 장치를 사용합니다.
2. 응용 프로그램에 GUI를 추가하고 여전히 모의 데이터베이스를 사용합니다.
3. 통합 테스트에서 자동화된 테스트 스크립트 (예 : 크루즈 컨트롤)를 사용하여 테스트 데이터가 포함된 실제 데이터베이스에 대해 응용 프로그램을 구동합니다.
4. 실제 사용에서는 응용프로그램을 사용하여 실시간 데이터베이스에 액세스하는 사용자와 함께 사용할 수 있습니다.

 

샘플 코드

포트 와 어댑터를 보여주는 가장 간단한 응용 프로그램은 다행히도 FIT 설명서와 함께 제공됩니다. 간단한 할인 계산 응용 프로그램입니다.

 
discount(amount) = amount * rate(amount);

금액은 사용자의 데이터가 될 것이고 비율은 데이터베이스에서 올 것 이므로 두 개의 포트가 있을 것입니다. 우리는 그것을 단계적으로 구현합니다 :

• 모의 데이터베이스 에서 제공되는 일정한 비율값으로 테스트
• 그리고나서 GUI와 함께,
• 모의 데이터베이스를 실제 데이터베이스로 변경하여 테스트 합니다.

이 예제의 코드를 제공한 IHC의 Gyan Sharma 에게 감사합니다.

 

1 단계 : FIT 앱 상수 - 모의 데이터베이스

먼저 테스트 케이스를 HTML 테이블로 만듭니다 (이에 대한 FIT 설명서 참조).

 
TestDiscounter
amount    discount()
100       5
200       10

열 이름은 프로그램의 클래스 및 함수 이름이 됩니다. FIT에는 이 "promrammerese"를 제거하는 방법이 포함되어 있지만여기서는 이를 남겨 두는 것이 더 쉽습니다.

테스트 데이터가 무엇인지 알고, 사용자 측 어댑터인 FIT와 함께 제공되는 ColumnFixture를 만듭니다.

 
import fit.ColumnFixture; 
public class TestDiscounter extends ColumnFixture 
{ 
   private Discounter app = new Discounter(); 
   public double amount;
   public double discount() 
   { return app.discount(amount); } 
}

어댑터에 실제로 있는 것은 이것이 전부입니다. 테스트는 명령 줄에서 실행됩니다. (필요한 경로에 대해서는 FIT 설명서 참조)

다음과 같이 실행했습니다 :

 
set FIT_HOME=/FIT/FitLibraryForFit15Feb2005
java -cp %FIT_HOME%/lib/javaFit1.1b.jar;%FIT_HOME%/dist/fitLibraryForFit.jar;src;bin
fit.FileRunner test/Discounter.html TestDiscount_Output.html

FIT는 통과 한 것을 우리에게 보여주는 컬러 파일을 출력합니다 (어딘가에서 오타를 냈을 경우 실패합니다).

이제 코드를 체크인 하고, Cruise Control 이나 자동화된 빌드 머신에 연결하여, 빌드 및 테스트 스위트에 포함 할 준비가 된것입니다.

2 단계 : UI 앱 상수 - 모의 데이터베이스

자신의 UI를 만들고 Discounter 응용 프로그램을 구동하도록 하겠습니다. 코드가 여기에 포함하기엔 길기 때문에, 코드의 핵심만 다음과 같이 표시합니다.

 
...
 Discounter app = new Discounter();
public void actionPerformed(ActionEvent event) 
{
    ...
   String amountStr = text1.getText();
   double amount = Double.parseDouble(amountStr);
   discount = app.discount(amount));
   text3.setText( "" + discount );
   ...

이제 응용 프로그램에 대해 데모 및 회귀 테스트 할 수 있습니다. 사용자측 어댑터는 모두 실행 중입니다.

 

3 단계 : (FIT 또는 UI) 앱 모의 데이터베이스

데이터베이스를 교체 가능하도록 어댑터를 만들려면 repository에 'Interface'를 작성하고 모의 데이터베이스 또는 실제 서비스 객체를 생성하는 'Repository Factory'와 데이터베이스에 대한 메모리 내 모의 객체를 만듭니다.

 
public interface RateRepository 
{
   double getRate(double amount);
}
​
​
public class RepositoryFactory 
{
   public RepositoryFactory() {  super(); }
   public static RateRepository getMockRateRepository() 
   {
      return new MockRateRepository();
   }
}
​
​
public class MockRateRepository implements RateRepository 
{
   public double getRate(double amount) 
   {
      if(amount <= 100) return 0.01;
      if(amount <= 1000) return 0.02;
      return 0.05;
    }
}

이 어댑터를 Discounter 응용 프로그램에 연결하려면 응용 프로그램 자체를 업데이트할 필요가 있습니다. (FIT 또는 UI) 사용자 측 어댑터가 사용할 Repository(실제 또는 모의)를 생성자에 전달해야 합니다. 다음은 모의 저장소를 전달하는 FIT 어댑터와 업데이트된 응용 프로그램입니다 (모의 또는 실제 저장소의 어댑터를 전달할지 여부를 선택하는 FIT 어댑터 코드는 늘어난 길이에 비해 새로운 정보가 없기 때문에 생략합니다).

 
import repository.RepositoryFactory;
import repository.RateRepository;
public class Discounter 
{
   private RateRepository rateRepository;
   public Discounter(RateRepository r) 
   {
      super();
      rateRepository = r;
    }
   public double discount(double amount) 
   {
      double rate = rateRepository.getRate( amount ); 
      return amount * rate;
    }
}

 
import app.Discounter;
import fit.ColumnFixture;
public class TestDiscounter extends ColumnFixture 
{
   private Discounter app = 
       new Discounter(RepositoryFactory.getMockRateRepository());
   public double amount;
   public double discount() 
   {
      return app.discount( amount );
   }
}

이것으로 가장 단순한 육각형 구조의 구현이 마무리되었습니다.

Ruby와 Rack 브라우저에 사용된 다른 구현 방법에 대해서는 https://github.com/totheralistair/SmallerWebHexagon을 참조하십시오.

 

애플리케이션 노트

좌우 비대칭

포트와 어댑터 패턴은 모든 포트가 근본적으로 유사하도록 의도되었습니다. 이는 아키텍처 차원에서 유용합니다. 포트와 어댑터는 두 가지 형태로 구현합니다. 나는 명확한 이유로 이것을 "primary" 및 "secondary" 라고 부릅니다. 다른 사람들은 "driving" 어댑터 와 "driven" 어댑터라고 부르기도 합니다.

주어진 모든 예에서 눈치를 챘을거라 생각하지만, 왼쪽 포트는 모의객체가, 오른쪽 포트는 실제 사용되는 FIT가 있다는 것을 알게됩니다. 3 계층 아키텍처에서 FIT는 최상위 레이어에 배치되고 모의객체는 맨 아래 레이어에 배치됩니다.

이것은 "primary actors"와 "secondary actors"의 사용 사례에서 비롯된 아이디어와 관련이 있습니다. "primary actors"는 애플리케이션을 구동하는 액터입니다 (기능 중 하나를 수행하기 위해 대기 상태에서 벗어납니다). "secondary actors"는 응용 프로그램이 응답을 얻거나 단순히 알리도록 유도하는 것입니다. "primary" 와 "secondary"의 구분은 누가 대화를 유발하거나 담당하는지에 있습니다.

"primary" 액터를 대체할 테스트 어댑터는 FIT입니다. 이 프레임워크는 스크립트를 읽고 응용 프로그램을 구동하도록 설계되었습니다. 데이터베이스와 같은 "secondary" 액터를 대신 할 테스트 어댑터는 응용 프로그램에서 쿼리에 응답하거나 이벤트를 기록하기 위해 고안된 모의객체 기법입니다.

이러한 관찰은 시스템의 유스케이스 컨텍스트 다이어그램을 따르며, 육각형의 왼쪽(또는 최상위) 에 "primary ports" 와 "primary adapters" 를 그리고, "secondary ports" 와 "secondary adapters" 는 육각형의 오른쪽 또는 아래쪽에 그립니다.

primary 및 secondary 포트/어댑터간의 관계는 FIT 와 모의객체의 각각의 구현에 유용 할 수 있습니다. 포트와 어댑터 아키텍처는 단락시키지 않도록 사용되어야 합니다. 포트와 어댑터 구현의 궁극적인 이점은 완전한 격리 모드에서도 응용 프로그램을 실행할 수 있다는 것입니다.

 

사용 사례 및 응용 프로그램 경계

육각형 아키텍처를 사용하면, 유스케이스를 작성하는 방법을 강화하는데 유용합니다.

유스케이스를 작성하는데 발생하는 일반적인 실수는 각 포트 외부에있는 기술에 대한 자세한 정보를 포함하는 것입니다. 이러한 유스케이스는 길고, 읽기 어렵고, 지루하고, 부서지기 쉽고 유지 보수 비용이 많이 들기 때문에 업계에서 오랫동안 악명을 얻었습니다.

포트와 어댑터 아키텍처를 이해하면, 외부 기술에 관계없이, 응용프로그램에서 지원하는 기능 및 이벤트를 명확하게 하기 위해, 응용프로그램의 경계(육각형으로된)가 작성된 일반적인 유스케이스를 볼수 있습니다. 이러한 유스케이스는 더 짧고, 읽기 쉽고, 유지 보수 비용이 적고, 시간이 지남에 따라 더 안정적입니다.

 

포트가 몇개나 되는가?

포트가 정확히 무엇인지는 대체로 경험의 문제입니다. 극단적인 경우에는 모든 유스케이스에 자체 포트가 주어질 수 있으므로 많은 애플리케이션을 위한 수백 개의 포트를 생성 할 수도 있습니다. 또는 모든 primary 포트와 secondary 포트를 합쳐서 왼쪽과 오른쪽의 두 포트만 있을 수도 있습니다.

양쪽 모두 최선은 아닙니다.

알려진 사용법에서 설명되는 기상시스템은 4개의 포트(날씨 정보, 관리자, 고지 받을 구독자, 구독자 데이터베이스)를 가지고 있습니다. 커피 머신 컨트롤러도 4개의 포트(사용자, 레시피와 가격을 가지고 있는 데이터베이스, 자동판매기와 동전 상자)를 가지고 있습니다. 병원의 투약 시스템은 3개(간호사, 처방 데이터베이스, 컴퓨터로 제어되는 약물 분배기)가 있습니다.

"틀린" 포트수를 선택하더라도, 특별한 문제가 있는 것으로 보이지 않으므로, 직관의 문제입니다. 위의 설명과 알려진 사용법에서 설명한 것처럼 나는 2, 3, 4개의 작은 숫자을 선택하는 경향이 있습니다.

 

알려진 사용법

Figure 4 : Hexagonal architecture complex example.gif

Figure 4는 각 포트에 4개의 포트와 여러 어댑터가 있는 응용 프로그램을 보여줍니다. 이것은 지진, 토네이도, 화재 및 홍수에 관한 기상청의 경고를 듣고, 사람들에게 전화 또는 자동 응답기로 알리는 응용 프로그램에서 파생되었습니다. 이 시스템을 논의 할 당시, 시스템의 인터페이스는 "목적과 관련된 기술"에 의해 식별되고 논의되었습니다. 유선 데이터를 통해 도착하는 트리거 데이터, 자동 응답기로 전송할 알림 데이터, GUI로 구현된 관리 인터페이스 및 데이터베이스에서 수신자 데이터를 가져 오는 인터페이스가 있었습니다.

사람들은 기상청의 HTTP 인터페이스, 이메일 인터페이스를 추가하는데 어려움을 겪고 있었고, 다양한 고객을 위해 응용프로그램에 추가하거나, 제거하는 방법을 찾아야했습니다. 그들은 모든 조합과 교체를 위해 별도의 버전을 구현하고 테스트 및 유지해야되서 유지 보수 및 테스트라는 악몽을 몹시 두려워했습니다.

그들의 디자인의 변화는 시스템의 인터페이스를 기술이 아닌 "목적"에 따라 설계하고, 기술은 어댑터로 대체 할 수 있게 하는 것이었습니다. 즉시 HTTP 피드와 이메일 알림을 포함할 수 있다는 것을 알았습니다. (새 어댑터는 그림에서 점선으로 표시). 각 응용 프로그램은 API 를 통해 headless 모드로 실행 가능하게 되어, 응용프로그램간 어댑터를 추가하고 해제할 수 있어, 하위 응용 프로그램을 필요에 따라 연결할 수 있습니다. 마지막으로 테스트 및 모의 (mock) 어댑터를 사용하여 각 응용 프로그램을 완전히 독립적으로 실행할 수 있게 하여 독립 실행형 자동화 테스트 스크립트로 응용 프로그램을 회귀 테스트 할 수 있었습니다.

 

Mac, Windows, Google, Flickr, Web 2.0

1990 년대 초, 워드 프로세서 응용 프로그램과 같은 MacIntosh 응용 프로그램에는 API 구동 가능 인터페이스가 있어야 응용 프로그램과 사용자 작성 스크립트가 응용 프로그램의 모든 기능에 액세스 할 수 있었습니다. Windows 데스크톱 응용 프로그램은 동일한 기능을 발전 시켰습니다 (어느 것이 먼저 왔는지, 그 점과 관련이 있는지에 대한 역사적인 지식이 없습니다).

웹 애플리케이션의 현재 (2005) 추세는 API를 공개하고 다른 웹 애플리케이션이 해당 API에 직접 액세스 할 수 있게 하는 것입니다. 따라서 Google지도를 통해 지역 범죄 데이터를 게시하거나 Flickr의 사진 보관 및 주석 달기 기능이 포함 된 웹 응용 프로그램을 만들 수 있습니다.

이 모든 예제는 "primary" 포트 API를 볼 수있게 하는 것에 관한 것입니다. secondary 포트에 대한 정보는 여기에 없습니다.

 

저장된 출력

이 예는 Willem Bogaerts가 C2 wiki에 쓴 것입니다.

나도 비슷한 일이 있었는데, 주로 응용 프로그램 계층이 관리 하지 말아야 하는 것 까지 관리하는 일종의 전화 교환기가 되었기 때문이었다. 내 응용 프로그램은 출력을 생성하여 사용자에게 보여 주었고 이를 저장할 수 있었습니다. 가장 큰 문제는 항상 저장할 필요가 없다는 것이었습니다. 그래서 내 응용 프로그램은 출력을 생성하고 그것을 버퍼링하여 사용자에게 보여줘야 했습니다. 그런 다음 사용자가 출력을 저장하기로 결정했을 때 응용 프로그램은 버퍼를 검색하여 저장했습니다.

나는 이것을 전혀 좋아하지 않았습니다. 그런 다음 해결책을 생각해 냈습니다. 저장소가 프리젠테이션 컨트롤을 가지도록 합니다. 이제 응용 프로그램은 다른 방향으로 출력을 하는 채널을 사용하지 않으며, 단순하게 프레젠테이션 컨트롤로 출력합니다. 프리젠테이션 컨트롤러는 사용자의 응답에 따라 버퍼를 저장 합니다.

전통적인 계층화 된 아키텍처는 "UI" 와 "저장소"가 서로 다른 것을 강조합니다. 포트와 어댑터 아키텍처는 출력이 단순히 다시 "출력" 되도록 강제 할 수 있습니다.

 

C2-wiki의 익명 예제

제가 한 프로젝트에서 우리는 컴포넌트 스테레오 시스템의 SystemMetaphor를 사용했습니다. 각 구성 요소에는 정의 된 인터페이스가 있으며 각 인터페이스에는 특정 용도가 있습니다. 우리는 간단한 케이블과 어댑터를 사용하여 구성 요소를 거의 무제한으로 연결할 수 있습니다.

 

분산 된 대규모 팀 개발

이것은 아직 시험 사용 중이므로 패턴의 사용으로 넣는 것은 적절하지 않습니다. 그러나 고려하는 것은 흥미롭습니다.

서로 다른 위치에 있는 팀이 모두 FIT 및 모의객체를 사용하여 육각형 구조를 구축하므로 응용 프로그램 또는 구성 요소를 독립 실행 형 모드에서 테스트 할 수 있습니다. CruiseControl 빌드는 30 분마다 실행되며 FIT + 모의객체의 조합을 사용하여 모든 응용 프로그램을 실행합니다. 응용 프로그램의 서브 시스템 및 데이터베이스를 가져오는 것이 완료되면 모의객체가 테스트 데이터베이스로 대체됩니다.

 

UI와 어플리케이션 로직의 분리 개발

이것은 아직 시험 사용 중이므로 패턴 사용으로 간주할 수 없습니다. 그러나 고려하는 것은 흥미 롭습니다.

UI 디자인은 운전 기술이나 메타포를 아직 결정하지 않았기 때문에 불안정합니다. 백엔드 서비스 아키텍처는 아직 결정되지 않았으며 실제로 향후 6 개월 동안 여러 번 변경 될 것입니다. 그럼에도 불구하고 이 프로젝트는 공식적으로 시작되었으며 시간은 계속 지켜봐야합니다.

응용 프로그램팀은 응용 프로그램을 격리하기 위해 FIT 테스트 및 모의 객체를 만들고 사용자에게 보여줄 수있는 검증 가능하고 입증 가능한 기능을 만듭니다. UI 및 백엔드 서비스 결정이 마침내 충족되면 해당 요소를 응용 프로그램에 추가하는 것이 "간단해야 합니다". 이 기술이 어떻게 작동하는지 배우기 위해 계속 지켜봐주십시오. (또는 직접 시도해보고 알려 주시면됩니다.)

 

연관된 패턴들

Adapter

디자인 패턴 책은 일반적으로 Adapter 패턴에 대한 설명을 포함하고 있습니다. 클래스의 인터페이스를 클라이언트가 기대하는 다른 인터페이스로 변환하는 포트와 어댑터 패턴은 Adpater 패턴의 하나의 사용방법입니다.

 

Model-View-Controller

MVC 패턴은 1974년 초에 Smalltalk 프로젝트에서 구현되었습니다. 수년에 걸쳐 Model-Interactor 와 Model-View-Presenter 같은 다양한 변형이 생성되었습니다. 모두 포트와 어뎁터의 Secondary 포트가 아닌 Primary 포트를 구현하고 있습니다.

 

Mock Objects and Loopback

모의객체는 다른 객체의 행동을 테스트 하기 위한 "이중간첩" 입니다. 첫째, 모의 객체는 실제 구현의 외부 동작을 모방하는 인터페이스 또는 클래스의 가짜 구현 역할을합니다. 둘째, 모의 객체는 다른 객체가 메서드와 상호 작용하는 방식을 관찰하고 실제 동작을 미리 설정된 기대치와 비교합니다. 불일치가 발생하면 모의객체가 테스트를 중단하고 이상을 보고할 수 있습니다. 테스트 중에 불일치가 발생하지 않는 경우 모든 기대가 충족되는 것을 보장합니다. 그렇지 않으면 실패가 보고됩니다. - From http://MockObjects.com

모의 대상 의제에 따라 완전히 구현된 모의 객체는 외부 인터페이스뿐만 아니라 응용 프로그램 전체에서 사용 됩니다. 모의 객체의 기본은 개별 클래스 및 객체 레벨에서 지정된 프로토콜을 준수하는 것입니다. 나는 "mock" 이라는 단어를 외부의 secondary 액터를 위한 인메모리 대체에 대한 가장 간단한 설명으로 사용하고 있습니다.

Loopback 패턴은 외부 장치를 위한 내부의 대안을 만들 명시적인 패턴입니다.

 

Pedestals

"Patterns for Generating a Layered Architecture" 에서 Barry Rubel은 제어 소프트웨어에서 대칭 축을 만드는 패턴을 설명합니다. 이것은 포트와 업댑터 패턴과 매우 유사 합니다. Pedestal 패턴은 시스템의 각 하드웨어 장치를 나타내는 객체의 구현을 필요로 하고 그 객체를 제어 레이어로 연결 합니다. Pedestal 패턴은 육각형 아키텍처의 양쪽을 설명하는데 사용할 수 있지만, 어뎁터 사이의 유사성을 강조하지는 않습니다. 또한, 기계 제어 환경을 위해 작성 되어서, IT 애플리케이션이 이 패턴을 적용하는 것은 쉽지 않습니다.

 

Checks

사용자의 입력 오류를 탐지하고 처리하기 위한 Ward Cunningham의 패턴은 육각형 경계의 내부에서 오류 처리하기에 좋습니다.

 

Dependency Inversion(Dependency Injection) and SPRING

Bob Martin은 Depledency Inversion(Martin Fowler의 Dependency Injection 이라고도 함) 에서

고수준 모듈은 저수준 모듈에 의존해서는 안됩니다. 추상화는 세부사항에 의존해서는 안되며, 세부사항은 추상화에 의존해야 합니다.

라고 말했습니다. Martin Fowler의 "Dependency Injection" 패턴은 몇 가지 구현을 제공합니다. 이 기능은 교환 가능한 secondary 액터 어뎁터를 만드는 방법을 보여 줍니다. 코드는 이 기사의 샘플 코드에서와 같이 직접 입력하거나 구성 파일을 사용하고 SPRING 프레임워크에서 동일한 코드를 생성하도록 할 수 있습니다.

 

감사 인사

여기에 사용 된 샘플 코드를 제공 한 Intermountain Health Care의 Gyan Sharma에게 감사드립니다. Rebecca Wirfs-Brock에게 'Design Patterns'책의 'Adapter'패턴과 함께 읽을 때 육각형이 무엇인지를 이해하는 데 도움이 되는 책인 'Object Design'에 감사드립니다. Ward의 wiki에있는 사람들에게 감사 드리며, 수년 동안이 패턴에 대한 의견을 제공했습니다 (예 : 특히 Kevin Rutherford의 http://silkandspinach.net/blog/2004/07/hexagonal_soup.html).

 

References and Related Reading

• FIT, A Framework for Integrating Testing: Cunningham, W., online at http://fit.c2.com, and Mugridge, R. and Cunningham, W., ‘’Fit for Developing Software’’, Prentice-Hall PTR, 2005.
• The ‘’Adapter’’ pattern: in Gamma, E., Helm, R., Johnson, R., Vlissides, J., ‘’Design Patterns’’, Addison-Wesley, 1995, pp. 139-150.
• The ‘’Pedestal’’ pattern: in Rubel, B., “Patterns for Generating a Layered Architecture”, in Coplien, J., Schmidt, D., ‘’PatternLanguages of Program Design’’, Addison-Wesley, 1995, pp. 119-150.
• The ‘’Checks’’ pattern: by Cunningham, W., online at http://c2.com/ppr/checks.html
• The ‘’Dependency Inversion Principle’‘: Martin, R., in ‘’Agile Software Development Principles Patterns and Practices’’, Prentice Hall, 2003, Chapter 11: “The Dependency-Inversion Principle”, and online at http://www.objectmentor.com/resources/articles/dip.pdf
• The ‘’Dependency Injection’’ pattern: Fowler, M., online at http://www.martinfowler.com/articles/injection.html
• The ‘’Mock Object’’ pattern: Freeman, S. online at http://MockObjects.com
• The ‘’Loopback’’ pattern: Cockburn, A., online at http://c2.com/cgi/wiki?LoopBack
• ‘’Use cases:’’ Cockburn, A., ‘’Writing Effective Use Cases’’, Addison-Wesley, 2001, and Cockburn, A., “Structuring Use Cases with Goals”, online at http://alistair.cockburn.us/crystal/articles/sucwg/structuringucswithgoals.htm

---

1 GUI가 없는 상태↩

2 MS Word 등으로 만든 HTML 테이블로 작성된 내용을 바탕으로 테스트 케이스를 자동 생성 해 주는 도구. 고객의 도메인 지식을 활용하여 초기부터 개발에 관여 할 수 있게 해준다. http://fit.c2.com/wiki.cgi?IntroductionToFit ↩