마이크로서비스 아키텍처 구축(전면 개정판)

116

1

부

기초

고 생각한다. 하지만 경우마다 다르다. 실제로는 ‘도메인 주도’를 마이크로서비스 경계를 정의

하는 중요 메커니즘으로 결정한 경우에도 모델을 혼합해야 할 이유가 흔히 나타난다.

지금까지 설명한 다양한 메커니즘 사이에는 잠재적으로 많은 상호작용이 있다. 그러므로 메커

니즘과 관련해 선택의 폭이 너무 좁으면 옳은 일을 하기보다는 ‘독단적 교리’를 따르게 된다. 변

동성 기반 분해는 전달 속도 향상에 중점을 뒀다면 매우 적합하지만, 이에 따라 조직 경계에

걸쳐 있는 서비스를 추출하게 된다면 전달 경합

delivery

contention

으로 인해 변경 속도가 저하될 수

있다.

비즈니스 도메인에 대한 이해를 바탕으로 멋진 창고 서비스를 정의할 수 있지만, 이 시스템의

한 부분은

C

++로 구현하고 다른 부분은 코틀린

Kotlin

으로 구현해야 한다면 해당 기술 경계에 따

라 더 분해해야 한다.

조직 및 도메인 주도 서비스의 경계는 나 자신만의 출발점이며 기본적인 접근법일 뿐이다. 일

반적으로 여기에 설명된 여러 요소가 영향을 주며, 어떤 요소가 여러분의 결정에 영향을 줄 것

인지는 해결할 문제에 달려 있다. 자신에게 가장 적합한 요소를 결정하려면 여러분이 처한 특

정 상황을 살펴봐야 하는데, 여러분이 고려할 만한 몇 가지 다른 선택지를 필자가 제공했길 기

대한다. 누군가가 “이 작업을 수행하는 유일한 방법은

X

입니다!”라고 말한다면, 그들은 아마도

독단적 교리를 팔고 있을 가능성이 높다. 여러분은 그것보다 더 잘할 수 있다.

지금부터는 도메인 ...