개념의 생명주기로 도메인 경계를 찾는 법

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

도메인 경계를 찾으려면 개념이 언제 생성되고, 함께 조회되고, 따로 바뀌며, 삭제되는지 비교한다. 계속 같은 시점에 움직이는 개념은 응집도가 높다. 서로 참조하더라도 생명주기는 다를 수 있다.

네 가지 생명주기 질문으로 시작한다

서비스의 개념을 펼쳐 놓고 서로를 비교한다.

• 같은 순간에 생성되는가?
• 보통 함께 조회되는가?
• 한쪽만 수정될 수 있는가?
• 하나를 삭제하면 다른 것도 반드시 삭제되는가?

상품, 필수 상품 아이템, 선택 옵션은 생성 시점부터 다르게 움직일 수 있다. 조회할 때는 모두 함께 나오더라도 옵션은 필수가 아니고 독립적으로 바뀌므로 결합이 더 약할 수 있다. 질문 하나가 경계를 결정하지 않는다. 네 관점에서 반복되는 패턴을 본다.

관련이 있다는 것과 생명주기가 같다는 것은 다르다

찜은 상품을 참조하지만 사용자가 나중에 만든다. 상품이 사라지면 찜도 없앨 수 있고, 사용자가 찜했던 상품이 만료됐다고 보여 줄 수도 있다. 어느 요구사항이든 가능하다. 두 경우 모두 찜과 상품의 생명주기가 완전히 같지는 않다.

이 차이를 알면 응집과 결합을 나눠 볼 수 있다. 서로 영향을 주는 개념도 같은 생명주기나 경계에 속하지 않을 수 있다. 결제 취소가 정산에 영향을 준다고 해서 결제와 정산이 반드시 같은 주기를 가져야 하는 것은 아니다.

주문과 결제, 배송, 정산은 서로 다른 시간을 가진다

주문은 결제 전에 생기고 결제로 이어지지 않을 수도 있다. 취소를 결제 상태로 본다면 결제와 취소는 가깝다. 배송에는 준비, 이동, 완료 같은 별도 과정이 있다. 정산은 결제가 사실상 끝난 뒤 다른 일정으로 일어날 수 있다.

하나의 비즈니스 여정을 이룬다는 이유로 모두 한 경계에 넣으면 모델이 너무 무거워질 수 있다. 반대로 명사마다 쪼개는 것도 답은 아니다. 생성, 조회, 수정, 삭제와 응집도, 결합도를 서비스 요구사항 안에서 비교한다.

마지막 묶음은 요구사항이 결정한다

개념을 적고 후보 격벽을 그린 다음 가까운 것만 묶는다. 생성, 조회, 수정, 삭제와 응집도, 결합도를 기준으로 그 묶음을 비교한다. 제안한 생명주기가 맞는지는 서비스의 요구사항이 결정한다.

이 과정에 모든 커머스 서비스가 따라야 할 정답은 없다. 상품 삭제 뒤 찜을 남길지, 주문이 결제 상태를 소유할지, 취소가 정산에 어떻게 반영될지는 기획에 따라 달라진다. 생명주기 분석은 답을 대신 주지 않는다. “관련 있으니 같이 둔다”보다 구체적인 언어로 팀이 경계를 고칠 수 있게 해 준다.