part 9. 도메인 모델과 바운디드 컨택스트

도메인 모델과 바운디드 컨택스트

• 바운디드 컨넥스트란?
  • 도메인 내부에서 모델을 공유하게 될때 도메인 모델을 결정할 수 있는 범위를 정의한것
  • 하나의 바운디드 컨텍스트는 하나의 프로젝트를 일반적으로 의미함

도메인 모델과 경계

• 유사한 요구사항에 의해 여러 도메인에서 하나의 물리적 모델을 공유 하고자 할때가 있는데 이 경우 서로의 개념이 섞이지 않도록 명시적으로 구분되는 경계를 가져서 섞이지 않도록 하는 범위

바운디드 컨텍스트

• 서로 다른 요구사항을 원하기 때문에 같은 도메인이더라도 달라 질 수 있음
• 하나의 컨택스트 내부에서는 고유한 의미로 사용됨
• 해당 역할만 충실하게 수행할 수 있는 데이터로 활용

바운디드 컨텍스트의 구현

• 조회전용 DB와 domain을 분리해서 사용하라.
• pagination 에 의한 니즈가 필요하다 → (예전의 판단) participants 라는 도메인을 생성하여 요구사항을 달성한다. → (지금의 판단) 해당 니즈를 위한 read db를 만들되 해당 요구사항이 도메인적인 역할을 수행하지 않도록 주의한다. → read DB를 만들고 싶은 훈의 니즈를 반영하고, 조가 말한 도메인 데이터를 복제해서 저장하는 문제를 완전히 분리할 수 있었을 것임. CQRS의 필요성
• DB에 저장하지 말고 domain 데이터는 외부에서 일관되게 가져와라 → 만약 pagination 과 같은 read 관련 요구사항이 발생하면 쿼리와 db를 분리하고 데이터를 새로 적재하도록 한다. 이때 domain 로직이 필요없도록 생성한다?
• 더 생각해보기

바운디드 컨텍스트 간 통합

• REST API로 데이터를 받아오는 방식
• push 방식으로 데이터를 가져오는 방식
  • 아마도 인스타그램에서 피드 가져오는 방식인듯?
  Designing Instagram: System Design Interview Question

바운디드 컨텍스트간 관계

• 외부 시스템의 모델이 내 도메인 모델을 침범하지 않도록 만들어주는 anticorruption layer를 생성해야함.
• 이 문제는 굉장히 자주 발생함.
• 어떻게 생각하는지 → infra layer에서 데이터를 항상 nullable 하게 받고 null check code를 만들어서 내 도메인에 맞게 데이터를 설정하는 방향에 대해