[DDD]CUSTOMER/SUPPLIER DEVELOPMENT TEAM

skayjays·2021년 11월 7일
2

DDD

목록 보기
8/16

문제점

  • 변경에 대한 거부권이 하류팀에 있거나 변경 요청절차가 지나치게 복잡하다면 상류 팀이 자유롭게 개발을 진행하는 데 하류팀에 속박당할 여지가 있다.
  • 상류 팀은 하류 시스템이 잘못될 것을 염려해서 개발 자체를 억제할지도 모른다.
  • 동시에 하류 팀은 상류 팀의 우선순위에 따라 좌지우지되기 때문에 무력해질 수 있다.

해결

  • 두팀간에 명확한 고객/공급자 관계를 확립하라.
  • 계획 회의에서 하류 팀이 상류 팀에 대한 고객 역할을 맡게 하라.
  • 하류 요구사항에 대한 작업을 협상하고 이에 대한 예산을 책정해서 모든 이들이 일정과 약속을 이행 할 수 있게 하라.
  • 결과로 예상되는 인터페이스를 검증하게 될 자동화된 인수테스트를 함께 개발하라.
  • 이 테스트를 상류 팀의 테스트 스위트에 추가해서 지속적인 통합의 일부로 실행되게하라.
  • 이러한 테스트를 토대로 상류 팀은 하류 시스템에서 발생할지도 모르는 부수효과를 두려워하지 않고 자유로이 코드를 변경할 수 있을 것이다.

중요한 요소

  • 관계는 고객과 공급자 간의 관계여야 한다.
  • 고객의 요구사항이 가장 중요하다.
  • 다른 고객의 요구사항 간의 균형을 맞춰야한다.
  • 자동화된 테스트 스위트가 마련되있어야 한다.

정리

  • 경계를 나누다 보면 상위 하위 레벨이 존재하게 된다. 그런데 서로 의존성을 갖다 보니 이러한 관계가 명백하지 않으면 서로 신경을 쓰게 되고 다양한 문제점이 생기기 마련이다. 그래서 자동화된 테스트 스위트를 통해 자유로이 코드를 변경할 수 있게 하는 게 중요하다고 생각한다.
profile
기초를 탄탄하게

1개의 댓글

comment-user-thumbnail
2021년 11월 8일

잘읽었습니다~!

답글 달기