SW/마이크로서비스

마이크로서비스 : 내부 설계를 위한 전술적 설계 및 주요 개념 : 정의, 개요, 설명

얇은생각 2020. 5. 22. 07:30
반응형

마이크로 서비스 내부 설계를 위한 전술적 설계 및 주요 개념

마이크로서비스는 도메인의 개념을 명확하고 자세히 표현하는 도메인 모델링을 통해 코드로 구현합니다. 즉, 전술적 설계란 전략적 설계를 통해 도출된 마이크로서비스의 내부를 상세히 설계하는 활동입니다.

전술적 설계는 도메인 주도 설계 개념에 나오는 용어로 비즈니스의 고유한 활동을 정확하게 모델링하는 설계 패턴과 방법입니다. 설계자는 이 절차와 다양한 기법들을 활용해서 개발하려는 서비스의 개념과 동작을 모델로 표현합니다.

이 전술적 설계의 진행 절차와 방법은 이전의 전략적 설계를 통해 식별했던 6개의 마이크로서비스로 구성된 쇼핑몰 시스템을 예제로 설명을 드리도록 하겠습니다.

 

 

마이크로 서비스의 내부 구조

마이크로서비스 : 내부 설계를 위한 전술적 설계 및 주요 개념 : 정의, 개요, 설명

 

마이크로서비스를 표현하는 6각형의 도형이 있습니다. 이 도형은 가운데에 도메인 계층이 존재하는 마이크로서비스의 내부 구조를 도식한 헥사고날 아키텍처를 표현한 그림입니다.

Client의 요청은 REST API 호출을 통한 Service Interface를 통해 도메인 모듈 내부로 전달됩니다. 또한 어댑터를 통해 다른 마이크로서비스와의 연계나 메시지 전달 또는 데이터베이스와의 연계합니다. 이 헥사고날 아키텍처는 그림에서 표현된 것처럼 기능 요구사항에 따라 애플리케이션의 내부, 즉 도메인 모델을 설계하고, UI, 데이터베이스 등 기술과 도메인 모델을 분리합니다.

고유한 비즈니스를 구현한 도메인과 기술의 분리는 다양하고 빠르게 바뀌는 UI, 데이터베이스 등의 기술의 변화에서 도메인을 격리시켜 보호합니다. UI, 데이터베이스 등 기술의 변경, 대체가 용이해지게 됩니다. 6각형의 도형을 보면 외부의 UI, 데이터베이스, 메시지 큐 등 다양한 기술을 활용합니다.

어댑터를 통해 중앙의 도메인 모델과 연결된, 즉 도메인 영역과 외부 기술영역을 완벽하게 분리됩니다. 새로운 기술의 추가나 기존 기술의 변경에도 어댑터의 추가 또는 변경만으로 도메인에 전혀 영향을 주지 않고 구성합니다.

 

 

도메인 주도 설계에서의 도메인 모델

소프트웨어 공학에서는 도메인 모델이란 특정 문제와 관련된 모든 주제의 개념모델입니다. 요구사항 분석 단계에서 개념 모델을 만들었습니다. 이 개념 모델이 도메인 모델에 해당됩니다.

이 도메인 모델은 고객, 제품책임자, 분석/설계자와 개발자가 잘 그려진 도메인 모델을 통해 도메인의 개념, 도메인의 정보, 도메인의 규칙을 서로 공유하고 이해를 맞출 수 있는 좋은 도구가 됩니다. 예전에는 분석가 또는 설계자가 이런 도메인 모델, CBD나 MDA에서는 PIM, 즉 플랫폼 독립 모델을 만들어서 개발자에게 전달해 주고 개발에는 관심을 두지 않았습니다. 어떤 경우는 프로젝트에서 빠지는 경우도 많이 있었습니다.

 

마이크로서비스 : 내부 설계를 위한 전술적 설계 및 주요 개념 : 정의, 개요, 설명

 

그런데 이 모델을 받은 개발자는 이 모델을 다시 구현을 위한 모델 PSM이라고 하는 플랫폼에 특화된 모델로 변환하고 그 후 실제 코드로 구현을 진행했습니다. 그런데 이 PIM이 PSM으로 변환되는 과정에서 PIM에서 잘 표현되었던 많은 도메인 지식들이 유실되거나 잘못 변경되면서 실제 원하는 소프트웨어가 만들어지지 않는 문제가 많이 발생하는 경우가 있습니다.

이런 도메인 모델과 구현 사이의 문제는 잘못된 소프트웨어를 만드는 큰 원인 중에 하나입니다. 도메인주도설계에서는 도메인 모델이란 특정 문제와 관련된 모든 주제의 개념모델이라고 정의합니다. 예전 방법론에서 요구사항 분석 단계에서 개념 모델을 만들었습니다. 이 개념 모델이 도메인 모델에 해당됩니다.

그러나 도메주도설계에서의 도메인 모델은 앞에서 설명했던 도메인 모델을 플랫폼에 특화된 모델로 변경하면서 발생되는 도메인의 유실 문제가 발생되지 않도록 모델의 구현까지 이어져 도메인의 개념이 코드까지 이어지는 것을 의미합니다.

 

마이크로서비스 : 내부 설계를 위한 전술적 설계 및 주요 개념 : 정의, 개요, 설명

 

이 도메인 모델을 확대해서 보면 화면에 보이는 클래스 다이어그램으로 표현된 모델이 도메인의 개념을 표현하는 도메인 모델의 각 객체를 볼 수 있습니다. 이 객체들은 소스코드 영역에 이 도메인 모델이 위치하는 model이라는 패키지 안에 그대로 코드로 변환되어 존재합니다.

Account 객체는 코드의 클래스로 표현됩니다. 도메인 모델도 클래스 다이어그램의 형태로 그려지는데 이 객체도 하나의 클래스로 그려집니다. Account 객체의 Name, Email, Member Type, Membership Level Type의 Attributes들은 실제 소스코드 Account 클래스 멤버 변수로 그대로 들어갑니다.

즉 도메인의 개념, 도메인의 정보, 도메인의 규칙을 정의하는 도메인 모델이 코드에 그대로 존재하게 되고 이를 기반으로 코드가 동작합니다. 이 도메인 모델은 UML의 클래스 다이어그램의 형태로 그려지게 됩니다. 따라서 도메인 모델링을 위해서는 기존의 UML 도구를 활용해서 그립니다.

 

 

도메인 모델의 표준 패턴

도메인 도멜링을 할 때 도메인 모델의 표준 패턴을 이해하고 활용해서 모델링을 하게 되면 각 패턴에 대한 사전 이해를 통해 고객과 제품책임자, 분석가, 도메인 모델러 그리고 개발자들 간에도 업무를 쉽게 이해할 수 있는 설계의 체계를 가질 수 있습니다.

 

 

엔티티 식별

중요한 패턴 중 하나인 Entity는 도메인 모델 내의 객체로 같은 형태를 띠거나 다른 형태의 Entity들과 특성을 구별할 수 있는 고유한 식별자를 갖고 있습니다. 또한 Entity는 상태가 변경될 수 있는데, 여러 번, 아니, 그 상태는 계속해서 변할 수 있습니다.

도메인 개념의 개별성을 인지할 때, 한 개념을 시스템 내의 나머지 모든 객체와 반드시 구분해야 하는 제약조건이 있을 때 이를 Entity로 설계합니다. 고유한 식별자와 변화 가능성이라는 특징이 Entity와 각 객체를 구분하는 큰 차이점이기도 합니다.

Entity를 설계할 때는 먼저 고유한 식별될 수 있는 특성과 행동을 중심으로 이를 조회하는 데 필요한 요소에 집중합니다. 다른 특성이나 행동을 식별하지 않습니다. 즉, 개념적으로 필수적인 행동과 그 행동에서 필요로 하는 특성만을 추가하는 것을 먼저 식별합니다. 이후 다른 특성과 행동을 식별하는 것이 좋습니다.

 

 

값 객체

주요한 패턴 중 또 하나인 값 객체는 Entity와 형태는 유사하지만 식별성이 없는 객체, 관련된 Entity의 속성을 표현하는 객체로 수정이 불가능한 값 그 자체를 표현합니다. 도메인 모델에서의 값은 그야말로 값으로 Entity와 달리 고유한 식별성이 없고, 값의 형태로 속성을 비교함으로써 값 객체를 비교할 수 있습니다.

보통 값 객체는 어떤 것을 나타낸다기보다는 Entity를 서술하거나 수량화하거나 측정하는 데 사용됩니다. 값 객체는 상태를 변경할 수 없는 객체로 모델링되어야 합니다. 개별 속성이 수정이나 삭제되지 않고 값 객체의 전체가 생성되거나 삭제되는 방식으로 동작합니다.

Address는 값 객체로 Address 내의 Zip 코드, 즉 우편번호의 변경은 Address 내의 Zip 코드만 수정되는 것이 아닌 새로운 Address 객체를 생성해서 기존 객체를 대체하는 방식으로 동작합니다.

 

 

표준 타입

다음은 표준 타입입니다. 표준 타입은 대상의 타입, 즉 유형을 나타내는 서술적 객체입니다. 대상을 의미하는 Entity나 설명을 의미하는 값 객체는 그 자체로 충분히 도메인을 표현할 수 있습니다. 그러나, 유형에 따라 해당 Entity를 구분해주는, 즉 대상의 타입을 표현하는 표준 타입의 객체가 필요하게 됩니다.

유비쿼터스 언어로 Account의 멤버를 정의했다면, 이러한 멤버 유형이 판매자인지 구매자인지 구분되게 모델링되어야 합니다. 만약 이 유형의 구분을 표준 타입이 아닌 판매자용과 구매자용의 별도의 클래스로 모델링합니다. 그러면, 유사한 개념의 객체를 유형별로 만들어 관리하게 되면 복잡해지고 관리가 어려워지게 됩니다. 그러므로 이런 구분이 필요한 경우에는 표준 타입을 이용해서 SELLER, BUYER로 멤버의 유형을 나타냅니다. 

반응형