업무중에 동료들이 아무리 생각해봐도 json 형식에 대해서 이야기하는것 같은데 contract 라는 단어를 써가면서 대화를 하고있었다.
일단 눈칫밥, 통밥으로 대화를 마무리하고 업무시간 이후에 사부님께 물었다.
“혹시 json 을 contract 이라고 말하기도 하나요?”
“음.. 서비스 간에 통신할때 계약관계라는 말을 쓰는데 거기서 나오는 contract 인가?
내가 지난번에 이야기할때 계약관계라고 말해준적이 있는데 혹시 기억하나?”
“아니요..”
“contract driven development 에서 나오는 contract 일꺼야.”
라는 이야기를 듣고 얼른 가서 나의 절친구글님께 물어보기 시작.
결국 반은 맞고 반은 틀리다.
시스템 간의 통신의 규약이 되는 것으로 모든시스템이 따로 분리되어서 개발되기때문에 통신규약이 필요한것이다. 이것을 컨트렉이라고 한다.
결과는 같게 하지만 서비스간 통신규약. 이 결국 contract 정도로 보면될것같고,
만약 http 기반의 json 으로 데이터를 주고받는다면 컨트렉의 형식이 제이슨 엔티티의 형식이 될수있으니 생각의 반은 맞고 반은 틀렸던것.(사실 컨셉상으로는 맞게 생각한 것이다.)
계약에 의한 설계는 곧 신뢰에 의한 프로그램인 것이다.
즉 선언적인 형태로 프로그램의 상태를 구분하고, 이를 통해 작성된 로직의 간결성을 유지하면서도 작성자의 의도를 명확히 전달한다
그래서 계약에 의한 설계에 의한 테스트 케이스는 따로 테스트 케이스를 작성하기 보다는 실제로 값이 입력되는 부분에 assert라는 키워드를 통해 특정 상황의 상태를 확증하는데 사용된다.
이것은 그런데 TDD 와 연관되어서 생각될 수 있다.