[keyword] 14장 모델의 무결성 유지 (1)

[emiling]

주제

'14장 - 모델의 무결성 유지(1)' 을 읽고 내용을 요약하거나,
중요✨ 하다고 생각하는 키워드 및 관련 설명을 코멘트로 달아주세요

연관 챕터

https://github.com/caffeine-library/Domain-Driven-Design/issues/57

[emiling]

Model Unification

• 아래 두 가지 안목을 결합하여 현새 상황을 명확히 나타내고 다른 이와 공유 가능한 형상을 만들어 낸다
  • 어떤 것을 단일화 해야하는지 에 관한 적극적인 의사 결정
  • 어떤 것을 단일화 해선 안되는지 를 실용적으로 인식하는 안목
• 그리고 단일화 되길 바라는 부분을 유지하고 단일화 되지 않은 부분이 혼란을 초래하거나 다른 부분을 손상시키지 않는지 확인한다
• 다른 여러 모델 간의 경계와 관계 를 분명하게 합의하는 것에서부터 출발

Bounded Context

• 모델이 올바른 상태로 유지되지 않았다면 그 원인은 팀이 조직되는 방식과 상호작용 에 있음
• 모델이 적용되는 컨텍스트를 명시적으로 정의하고 그 내부에선 모델을 엄격하게 일관된 상태로 유지해야함
  • 경계 바깥의 이슈 때문에 내부의 초점이 흐려지거나 혼란스러워지면 안됨
• Bounded Context로 어떤 부분에서 일관성을 지니고 어떤 식으로 다른 것과 연관됐는지를 이해할 수 있도록 특정 모델의 범위를 제한함

MODULE != BOUNDED CONTEXT

모델의 구성 단위로 구분해야할듯... 각각의 bounded context는 서로 다르게 구성되는 각각의 모델을 가지고 있는 게 맞지만, 하나의 모델 내의 여러 구성요소가 각기 다른 모듈로 구성될 수도 있기 때문에 개별 context에 의도를 전하는 것은 아님

경계 사이의 표현 방식이 다른 (dialect) 모델을 변역(translation)하는 역할은 모델에 의해 주도되는 것이 아님

두 팀이 같은 CONTEXT 안에 있지 않다면 어느 정도의 변화가 생기기 전까지는 코드를 공유하려해서는 안된다.

만약 모델의 단일화가 깨져서 개념적 균열이 발생한다면?

• 코드로 작성된 인터페이스가 서로 맞지 않거나 자동화된 CONTINUOUS INTEGRATION 프로세스를 통해 문제가 발견됨
• 중복된 개념 : 실제로 같은 개념을 나타네는 두 모델요소(혹은 이를 따르는 구현)가 존재
• 허위 동족 언어 : 같은 용어(혹은 구현 객체)를 사용하는 두 사람이 서로 같은 것을 이야기하고 있다고 생각하지만, 서로 다른 걸 얘기함

CONTINUOUS INTEGRATION

• BOUNDED CONTEXT 내부에서 단일화된 모델을 유지하는 방법
  • 내부적인 균열이 발생했을 때 빠르게 포착하도 컨텍스트 내의 작업을 빈번하게 병합하여 일관성을 유지한다
• 단편화가 발생했다는 것을 빠르게 알려줄 수 있는 자동화된 테스트 및 코드와 구현 산출물을 빈번히 병합하는 프로세스를 수립한다

Context Map

• 별개의 컨텍스트가 공존할 때 그 관계를 결정하고 필요한 인터페이스를 설정하는 방법
• 프로젝트와 컨텍스트와 각 컨텍스트 간의 관계의 전체적인 개관을 제공 (프로젝트 관리와 소프트웨어 설계 영역 사이에 걸침)
  • 각 모델의 적용 가능성의 범위를 측정하는 Bounded Context와 다름
  • 보통은 팀 조직의 윤곽을 따라 정해진다

Bounded Context 간에 코드를 재사용하는 것은 위험하므로 피하고 대신 기능과 데이터는 번역 과정을 거쳐 통합한다

MAP을 어떤 형식으로 작성하건 프로젝트에 속한 모든 사람은 MAP을 이해하고 공유해야한다. MAP은 BOUNDED CONTEXT의 명확한 이름을 제공해야하며, 경계 지점과 경계 지점의 특성을 명확하게 표현해야 한다.

Solutions

• SHARED KERNELS:
  • 독립된 두 팀에서 공유하기로 한 도메인 부분집합을 명시하고, 기능 시스템을 자주 통합함으로써 중복을 줄이고 통합을 용이하게 함
  • CUSTOMER/SUPPLIER DEVELOPMENT:
  • 서로 다른 BOUNDED CONTEXT 사이에서 한 쪽(upstream)이 다른 쪽(downstream)에 본질적으로 데이터를 제공하는 경우
    • 모든 의존성은 단방향으로 흐르고 수행하는 업무가 상이한 경우가 많음
  • 두 팀 사이의 공식적인 관계를 확립하고 XP의 반복 계획 프로세스를 활용하며, 예상되는 인터페이스에 대한 자동화된 인수테스트를 수행
• CONFORMIST:
  • 위 CUSTOMER/SUPPLIER 와 같은 협력패턴이 원할하게 적용되지 못한다면 맹목적으로 상류 팀의 모델을 준수하는 방법
  • 하류 팀의 설계 형식이 상류 팀에 소박되고 자체 어플리케이션을 위한 이상적인 모델을 만들진 못하지만 통합은 단순해짐
  • 상류 팀에 대한 의존성을 심화하고 어플리케이션을 상류 팀이 보유한 모델에서 제공하는 능력 내로 제한한다
  • 동일한 모델을 이용하고 다른 모델이 영향을 미치는 영역을 보유한다는 점에서 SHARED KERNELS와 유사하지만
  • 이는 밀접하게 조율가능한 두 팀 사이의 협력관계를 다루지만 CONFORMIST는 협력에 관심없는 팀과의 통합 문제를 다룸

[leejaeseung]

중복된 개념(366p)

실제로 같은 개념을 나타내는 두 개의 모델 요소(그리고 그것에 따르는 구현)가 존재하는 것이다.

이전에 중복 코드를 어디까지 공통화해야 하냐에 대한 얘기를 한 적이 있는데, 여기서 말하는 중복된 개념은 중복 코드와는 다른 개념이라고 생각됩니다.

중복 코드 : 변경 가능성이 있지만 현 시점에는 같은 정책을 적용해야 하는 코드들. 각기 다른 정책으로 변경될 수 있으므로 섣부를 공통화는 좋지 않음. 중복 개념 : 확실히 정의된 개념(혹은 정책)에 대해 같은 모델을 여러 번 구현한 것. 정책이 갱신될 때마다 여러 군데에 모두 적용해야 하므로 안정성이 떨어질 수 있어 공통화가 필수적임. (개념에 대한 일관성)

코드만 보면 둘다 중복된 코드이기 때문에 이를 잘 구분하는게 중요하다고 생각되어서 정리해 보았습니다.

[leejaeseung]

지속적인 통합의 안좋았던 예시

일전에 리팩토링을 하다가 기존 로직이 제대로 동작하지 않아 큰일날 뻔한 기억이 떠오르네요. 베타 테스트는 모두 성공했는데, 타 팀의 베타 테스트를 지원하다가 오류가 났던 케이스.. (테스트 지원이 없었으면 운영에서 에러가 날 뻔함..)

현재 정책에 맞게 하나의 클래스를 두 개의 클래스로 쪼개는 리팩토링이었는데, 그 과정에서 옛날 레거시 객체에 대한 주석을 무시했던게 화근이었습니다. (그때까진 주석을 남겨놓으면 안전하다고 생각했지만, 직접 경험해보니 주석조차도 무시될 수 있겠다는 교훈을 얻었죠..) 클래스를 새로 만들어 새로 작성하다보니 기존 주석을 볼 겨를이 없더라구요.. (복붙하면서 사라짐) 설상가상으로 테스트코드도 존재하지 않았습니다.

책에서도 지속적인 통합을 위해 자동화된 테스트 스위트를 강조하는데, 확실히 정책적으로 치명적인 부분에 대해선 테스트코드를 꼼꼼히 작성해야겠더라구요.

교훈 주석을 달아놨다고 안심하지 말자. (주석 대신 테스트코드를 믿자) 테스트코드를 잘 짜자.