기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

모범 사례

비즈니스 도메인 모델링

비즈니스 영역부터 소프트웨어 설계까지 다시 작업하여 작성 중인 소프트웨어가 비즈니스 요구 사항에 맞는지 확인하십시오.

이벤트 스토밍과 같은 도메인 기반 설계 (DDD) 방법론을 사용하여 비즈니스 도메인을 모델링합니다. 이벤트 스토밍에는 유연한 워크샵 형식이 있습니다. 워크숍 기간 동안 도메인 및 소프트웨어 전문가들은 비즈니스 도메인의 복잡성을 공동으로 탐구합니다. 소프트웨어 전문가는 워크숍의 결과물을 사용하여 소프트웨어 구성 요소의 설계 및 개발 프로세스를 시작합니다.

처음부터 테스트 작성 및 실행

테스트 주도 개발 (TDD) 을 사용하여 개발 중인 소프트웨어의 정확성을 검증하십시오. TDD는 단위 테스트 수준에서 가장 잘 작동합니다. 개발자는 먼저 테스트를 작성하여 해당 구성 요소를 호출하여 소프트웨어 구성 요소를 설계합니다. 해당 구성 요소는 처음에 구현되지 않았으므로 테스트가 실패합니다. 다음 단계로 개발자는 모의 객체와 함께 테스트 픽스처를 사용하여 외부 종속성 또는 포트의 동작을 시뮬레이션하여 구성 요소의 기능을 구현합니다. 테스트가 성공하면 개발자는 실제 어댑터를 구현하여 계속 진행할 수 있습니다. 이 접근 방식은 개발자가 사용자가 구성 요소를 사용하는 방법을 이해하기 때문에 소프트웨어 품질을 향상시키고 코드 가독성을 높입니다. 육각형 아키텍처는 애플리케이션 코어를 분리하여 TDD 방법론을 지원합니다. 개발자는 도메인 코어 동작에 초점을 맞춘 단위 테스트를 작성합니다. 테스트를 실행하기 위해 복잡한 어댑터를 작성할 필요가 없습니다. 대신 간단한 모의 객체와 픽스처를 사용할 수 있습니다.

행동 기반 개발 (BDD) 을 사용하여 기능 수준에서 end-to-end 수용을 보장하십시오. BDD에서 개발자는 기능에 대한 시나리오를 정의하고 비즈니스 이해관계자와 함께 이를 검증합니다. BDD 테스트는 이를 달성하기 위해 가능한 한 많은 자연어를 사용합니다. 육각형 아키텍처는 기본 및 보조 어댑터라는 개념으로 BDD 방법론을 지원합니다. 개발자는 외부 서비스를 호출하지 않고도 로컬에서 실행할 수 있는 기본 및 보조 어댑터를 만들 수 있습니다. 로컬 기본 어댑터를 사용하여 애플리케이션을 실행하도록 BDD 테스트 스위트를 구성합니다.

지속적 통합 파이프라인에서 각 테스트를 자동으로 실행하여 시스템 품질을 지속적으로 평가합니다.

도메인의 동작을 정의합니다.

도메인을 엔티티, 값 객체 및 애그리게이트로 분해하고 (도메인 기반 설계 구현에 대해 읽어보세요) 해당 동작을 정의합니다. 프로젝트 초기에 작성된 테스트가 성공하도록 도메인의 동작을 구현합니다. 도메인 객체의 동작을 호출하는 명령을 정의합니다. 도메인 객체가 동작을 완료한 후 내보내는 이벤트를 정의합니다.

어댑터가 도메인과 상호 작용하는 데 사용할 수 있는 인터페이스를 정의합니다.

테스트 및 배포 자동화

초기 개념 증명을 마친 후에는 DevOps 사례 구현에 시간을 투자하는 것이 좋습니다. 예를 들어 지속적 통합 및 지속적 전달 (CI/CD) 파이프라인과 동적 테스트 환경은 코드 품질을 유지하고 배포 중에 오류를 방지하는 데 도움이 됩니다.

마이크로서비스 및 CQRS를 사용하여 제품을 확장하세요

제품이 성공하면 소프트웨어 프로젝트를 마이크로서비스로 분해하여 제품을 확장하세요. 육각형 아키텍처가 제공하는 휴대성을 활용하여 성능을 개선하십시오. 쿼리 서비스와 명령 처리기를 별도의 동기 및 비동기 API로 분할합니다. 명령 쿼리 책임 분리 (CQRS) 패턴 및 이벤트 기반 아키텍처를 채택하는 것을 고려해 보십시오.

새로운 기능 요청을 많이 받는 경우 DDD 패턴에 따라 조직을 확장하는 것을 고려해 보세요. 이전조직 단위 섹션에서 설명한 것처럼 제한된 컨텍스트로 하나 이상의 기능을 소유하도록 팀을 구성하십시오. 그런 다음 이러한 팀은 육각형 아키텍처를 사용하여 비즈니스 로직을 구현할 수 있습니다.

육각형 아키텍처 개념에 맞는 프로젝트 구조를 설계하십시오.

코드형 인프라 (IaC) 는 클라우드 개발에서 널리 채택되고 있습니다. 이를 통해 인프라 리소스 (예: 네트워크, 로드 밸런서, 가상 머신, 게이트웨이) 를 소스 코드로 정의하고 유지할 수 있습니다. 이렇게 하면 버전 관리 시스템을 사용하여 아키텍처의 모든 변경 사항을 추적할 수 있습니다. 또한 테스트 목적으로 인프라를 쉽게 만들고 이동할 수 있습니다. 클라우드 애플리케이션을 개발할 때는 애플리케이션 코드와 인프라 코드를 동일한 리포지토리에 보관하는 것이 좋습니다. 이 접근 방식을 사용하면 애플리케이션의 인프라를 쉽게 유지 관리할 수 있습니다.

애플리케이션을 육각형 아키텍처의 개념에 맞는 세 개의 폴더 또는 프로젝트, 즉entrypoints (기본 어댑터), (도메인 및 인터페이스),domainadapters (보조 어댑터) 로 나누는 것이 좋습니다.

다음 프로젝트 구조는 API를 설계할 때 이러한 접근 방식의 예를 제공합니다AWS. 프로젝트는 앞서 권장한 대로 동일한 리포지토리에 애플리케이션 코드 (appinfra) 와 인프라 코드 () 를 유지 관리합니다.

app/  # application code
|--- adapters/  # implementation of the ports defined in the domain
     |--- tests/  # adapter unit tests
|--- entrypoints/  # primary adapters, entry points
     |--- api/  # api entry point
          |--- model/  # api model
          |--- tests/  # end to end api tests
|--- domain/  # domain to implement business logic using hexagonal architecture
     |--- command_handlers/  # handlers used to run commands on the domain
     |--- commands/  # commands on the domain
     |--- events/  # events emitted by the domain
     |--- exceptions/  # exceptions defined on the domain
     |--- model/  # domain model
     |--- ports/  # abstractions used for external communication
     |--- tests/  # domain tests
infra/  # infrastructure code 

앞서 설명한 것처럼 도메인은 애플리케이션의 핵심이며 다른 모듈에 의존하지 않습니다. 다음과 같은 하위domain 폴더를 포함하도록 폴더를 구성하는 것이 좋습니다.

기본 어댑터는entrypoints 폴더로 표시되는 응용 프로그램의 진입점입니다. 이 예에서는api 폴더를 기본 어댑터로 사용합니다. 이 폴더에는 기본 어댑터가 클라이언트와 통신하는 데 필요한 인터페이스를 정의하는model API가 들어 있습니다. tests폴더에는 API에 대한 end-to-end 테스트가 들어 있습니다. 이는 애플리케이션의 구성 요소가 통합되고 조화롭게 작동하는지 검증하는 간단한 테스트입니다.

adapters폴더로 표시된 보조 어댑터는 도메인 포트에 필요한 외부 통합을 구현합니다. 데이터베이스 리포지토리는 보조 어댑터의 좋은 예입니다. 데이터베이스 시스템이 변경되면 도메인에서 정의한 구현을 사용하여 새 어댑터를 작성할 수 있습니다. 도메인이나 비즈니스 로직을 변경할 필요가 없습니다. tests하위 폴더에는 각 어댑터에 대한 외부 통합 테스트가 들어 있습니다.