# REL03-BP02 특정 비즈니스 도메인 및 기능을 중심으로 서비스 구축
<a name="rel_service_architecture_business_domains"></a>

 서비스 지향 아키텍처(SOA)는 비즈니스 요구 사항에 따라 명확하게 정의된 기능으로 서비스를 구축합니다. 마이크로서비스는 도메인 모델과 경계 컨텍스트를 사용하여 이를 추가로 제한함으로써 각 서비스가 한 가지 작업을 수행하도록 합니다. 특정 기능에 집중하면 다양한 서비스의 안정성 요구 사항을 구분하고 보다 구체적으로 투자의 대상을 지정할 수 있습니다. 또한 비즈니스 문제가 간단해지고 각 서비스에 소규모 팀이 연결되므로 조직의 확장이 수월해집니다. 

 마이크로서비스 아키텍처를 설계할 때는 DDD(Domain-Driven Design)에서 엔터티를 사용하여 비즈니스 문제를 모델링하는 것이 도움이 됩니다. 예를 들어 Amazon.com 웹 사이트에서 엔터티에는 패키지, 배송, 일정, 가격, 할인 및 통화가 포함될 수 있습니다. 이 모델은 [https://martinfowler.com/bliki/BoundedContext.html](https://martinfowler.com/bliki/BoundedContext.html)를 사용하여 유사한 기능 및 속성을 공유하는 엔터티를 그룹화하는 더 작은 모델로 구분됩니다. 따라서 Amazon.com 예시 패키지에서 배송 및 일정은 배송 컨텍스트에 포함되지만 가격, 할인 및 통화는 요금 컨텍스트에 포함됩니다. 모델을 컨텍스트로 나누면 마이크로서비스의 경계를 지정하는 방법에 대한 템플릿을 사용할 수 있게 됩니다. 

![\[마이크로서비스의 경계 지정 방법을 위한 모델 템플릿\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/building-services.png)


 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>
+  비즈니스 도메인과 해당 기능을 기준으로 워크로드를 설계합니다. 특정 기능에 집중하면 다양한 서비스의 안정성 요구 사항을 구분하고 보다 구체적으로 투자의 대상을 지정할 수 있습니다. 또한 비즈니스 문제가 간단해지고 각 서비스에 소규모 팀이 연결되므로 조직의 확장이 수월해집니다. 
  +  도메인 분석을 수행하여 워크로드에 대한 DDD(도메인 중심 설계)를 매핑합니다. 그러면 워크로드의 요구 사항에 맞는 아키텍처 유형을 선택할 수 있습니다. 
    +  [모놀리식 유형을 마이크로서비스로 분할하는 방법](https://martinfowler.com/articles/break-monolith-into-microservices.html) 
    +  [레거시 시스템으로 둘러싸여 있을 때 DDD 시작](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf) 
    +  [Eric Evans ‘Domain-Driven Design: Tackling Complexity in the Heart of Software’](https://www.amazon.com/gp/product/0321125215) 
    +  [AWS에서 마이크로서비스 구현](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html) 
+ 가능한 한 가장 작은 구성 요소로 서비스를 분해합니다. 마이크로서비스 아키텍처를 사용하면 워크로드를 최소 기능 단위의 구성 요소로 분리하여 조직을 확장하고 민첩성을 실현할 수 있습니다. 
  +  워크로드 및 설계 목표, 한도 및 사용에 대한 기타 고려 사항과 관련하여 API를 정의합니다. 
    +  API 정의. 
      +  API 정의는 확장 및 추가 파라미터를 허용해야 합니다. 
    +  설계된 가용성 정의. 
      + API는 다양한 기능에 대해 여러 설계 목표를 가질 수 있습니다.
    +  한도 수립 
      +  테스트를 사용하여 워크로드 기능의 한도를 정의합니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [Amazon API Gateway: OpenAPI를 사용하여 REST API 구성](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html) 
+  [경계 컨텍스트(도메인 주도 설계의 주요 패턴)](https://martinfowler.com/bliki/BoundedContext.html) 
+  [Eric Evans ‘Domain-Driven Design: Tackling Complexity in the Heart of Software’](https://www.amazon.com/gp/product/0321125215) 
+  [레거시 시스템으로 둘러싸여 있을 때 DDD 시작](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf) 
+  [모놀리식 유형을 마이크로서비스로 분할하는 방법](https://martinfowler.com/articles/break-monolith-into-microservices.html) 
+  [AWS에서 마이크로서비스 구현](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html) 
+  [Microservice Trade-Offs](https://martinfowler.com/articles/microservice-trade-offs.html) 
+  [Microservices - a definition of this new architectural term](https://www.martinfowler.com/articles/microservices.html) 
+  [AWS 마이크로서비스](https://aws.amazon.com/microservices/)