인프런 커뮤니티 질문&답변

MSA는 클린 스프링 강의 시리즈 후반부에 다룰 주제인데 일찍 이야기가 나왔네요.

도메인 모델은 도메인의 지식을 담아두는 장치입니다. 그런데 MSA 처럼 전체 시스템을 보다 작은 단위의 경계를 기준으로 분리하는 경우에는 각각이 독립적인 보편 언어와 도메인 모델로 만들어지게 됩니다. 도메인 주도 설계에서는 이걸 바운디드 컨텍스트라는 이름으로 부르기도 하죠.

그런데 많은 경우 MSA가 이렇게 일관성을 지킬 수 있는 도메인 모델들의 조합이라는 관점에서 구분하지 않고, 적당한 기능 단위 또는 기술적인 이유로 인한 시스템 구성에 따른 단위로 쪼개기도 합니다. 이런 경우 불필요하게 나뉘어진 각 마이크로 서비스들은 엄밀히 말해서 독립적인 도메인 모델이 아닐 수도 있습니다. 마이크로 서비스 여러개를 묶어서 하나의 바운디드 컨텍스트로 잡아도 충분한데 이걸 억지로 쪼개두면 오히려 여러가지 모델 설계와 구현의 문제가 드러나기도 합니다. 이에 대해서는 MSA를 다룰 때 자세히 이야기 드리겠습니다.

어쨌든 여러 서비스가 구분되어 있을 때 필연적으로 다른 서비스가 소유하고 다루는 개념에서 만들어지는 데이터를 참고해서 나의 로직을 수행해야 할 수 있습니다. 단순히 연관관계를 위해서 레퍼런스 ID 값 정도를 받아서 저장해두기도 하지만, 때로는 로직 수행에 필요한 데이터를 받아 사용하기도 합니다. 이때 다른 마이크로 서비스로부터 가져온 데이터는 엄밀히 말해 자신의 서비스의 도메인 모델 자체로 설계될 이유는 없습니다. 데이터가 단편적이고 특정 엔티티와 연결시킬 이유가 없는 경우라면 더더욱 그렇습니다. 각각이 마이크로 서비스로 구분되어있다면 주문에서 상품 엔티티의 아이디 값을 받아 저장해두거나 필요한 경우 상품 마이크로 서비스에 정보를 요청할 수는 있겠지만, 상품 엔티티를 직접 가져와서 로직을 수행하는 작업을 할 이유는 없습니다.

때로는 다른 서비스 엔티티의 일부분을 스냅샷으로 가져와서 읽기 모델로 만들어 나의 로직을 수행할 때 참고하는 데이터로 쓸 수는 있습니다. 각각의 개념이 깊이 연결되는 로직인 경우는 그렇겠죠. 이때 해당 서비스가 소유한 도메인의 내부 로직을 침범하지 않도록 주의해야 합니다.

따라서 외부 개념 전체가 나의 도메인이다라고 할 수는 없습니다. 레퍼런스가 만들어지는 경우엔 다른 서비스의 개념과 연결된다 정도로 이야기하면 충분할 것 같고, 그 중에서 나의 로직을 수행할 때 어떤 데이터가 필요하다라는 것 정도만 정의하면 충분할 것 같습니다. 그렇지 않으면 자칫 다른 서비스 모델이 발전하거나 진화하면서 내 도메인 모델을 오염시킬 수도 있습니다.

MSA는 시스템의 규모가 커지고 시간이 오래 흐르면서 어느 단계에선가 필연적으로 도입이 필요합니다. 이제는 전체가 너무 복잡해져서 모든 걸 묶어서 하나의 도메인 모델로 만들면 이해하기가 불가능한 수준이 될 수도 있습니다. 그리고 전체 모델의 일관성이나 언어가 잘 지켜지지도 않고요. 이럴 때는 각각을 독립적인 도메인 모델로 만들고 느슨하게 연결 시킬 수 밖에 없겠죠. 하지만 도메인 관점이 아닌 기술적인 이유나 여타의 사정으로 MSA 서비스를 분리했을 경우엔, 필요하다면 두 개 이상의 서비스를 묶어서 하나의 도메인 모델로 보는 것이 나은 경우도 있을 듯합니다. 두 서비스가 하나의 서비스 안에 단지 모듈로 구분되어있을 때랑 아무 차이가 없다면요.

아무튼 어려운 주제의 질문이네요. 저도 좀 더 생각을 해보겠습니다.

안녕하세요, 인프런 AI 인턴입니다. 파파라파파님께서 던진 질문에 대해 답변드리겠습니다.

MSA(마이크로서비스 아키텍처) 환경에서 도메인 모델의 범위를 정의하는 것은 시스템 디자인의 핵심 요소 중 하나입니다. 말씀하신 것처럼, 도메인 모델이란 단순히 데이터를 생성하고 저장하는 것을 넘어 확장된 개념으로 이해하는 것이 중요합니다.

1. 도메인 모델의 확장성: 도메인 모델은 해당 시스템에서의 비즈니스 로직과 규칙을 포함하고, 외부 시스템과의 상호작용까지 포괄할 수 있는 영역으로 이해됩니다. 주문 시스템에서 다른 시스템의 데이터를 활용하여 비즈니스 규칙을 수행하는 것은 도메인 모델의 정의 범위를 확장시키는 훌륭한 예입니다.

2. ** bounded context**: 도메인 모델은 종종 한 시스템 내부에서 명확하게 정의된 경계를 가지며, 이는 DDD(Domain-Driven Design)의 개념 중 하나인 ‘Bounded Context’와 연결됩니다. 각 시스템(혹은 서비스)은 독자적인 도메인 모델을 관리하되, 타 시스템에 대한 의존성을 줄이고, 각자의 비즈니스 로직과 규칙을 중심으로 모델을 설계합니다.

3. 외부 데이터 추상화: 외부에서 유입되는 데이터라도, 해당 시스템 내에서의 비즈니스 로직을 처리하기 위해 다른 형태로 재정의하거나 추상화할 필요가 있을 수 있습니다. 이를 통해 시스템은 자신의 책임 하에 명확한 데이터를 다루며, 이 과정에서 도메인 모델의 경계와 책임이 더욱 분명해집니다.

관련된 논의를 위해, 이전에 토비님이 언급하신 내용을 참고하시기 바랍니다:
- 토비님이 생각하시는 복잡한 도메인은 무엇이라고 생각하시나요?
- 도메인에 대한 개인적인 경험이 다음 설계에 영향을 주는 경우가 많습니다. 토비님께서는 설계를 하실 때, 이전 경험에서 비롯된 도메인을 어느 정도까지 설계에 반영하시나요?

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.