Cohesion(응집성?)의 올바른 예와 나쁜 예
Cohesion(응집성?)의 올바른 예와 나쁜 예를 도식화하면 아래와 같다.
1. 매출을 유발하는 소프트웨어는 필연적으로 앞으로 나아간다.
2. 응집성이 떨어지는 소프트웨어, 시스템이 있으면 이런 변화를 즉시에 수용하기 힘들고 오류나 장애로 서비스 신뢰도와 매출이 급락한다.
3. 결국 DX가 바닥을 치게 되므로 "진짜" 키맨들이 퇴사할 것이다.
우리가 거창하게 아키텍처를 거들먹거리지만, 현실 세계로 이야기를 해보자. app1, app2 가 서로 다른 부서라면 a) 사례의 이상적인 그림은 누구나 납득할 것이며, b) 구조는 있어서는 안된다는 걸 적극 공감할 것이다.
또한 부서의 정의라는게 아주 강력하고 긴밀한 의존성과 협력 관계에 의해 정의된다는 것도 공감할 것이다.
따라서 조직(서비스, 시스템)을 새롭게 구성하고 일을 쌓아가는 과정에는 필연적인 "정리" 가 있어야 한다.
이것은 단순히 시스템 간 호출을 의미하는 걸 넘어 시스템 간 다루는 데이터 사이에도 적절한 이격거리를 통한 방화선 구축이 있어야 한다.
데이터에 대한 이격거리가 무엇인지도 현실세계로 비유하자면,
은행 현장 접수 시스템과 창구 시스템이 매우 느슨하게 연결되어 있음을 떠올려 보면된다. 접수번호로 고객의 존재를 식별하고, 할당된 창구에 가서 필요한 서비스를 받으면 그만이다.
덕분에 은행 업무가 변경 되어도 접수 시스템을 고칠 필요가 없다.
만약 은행의 접수 시스템에서 고객의 세부 목적과 계좌 정보를 입력 받고 창구가 할당되는 구조라면 어떨까 상상해보자.
고객이나 계좌에 대한 어떤 작업이나 변경이 있을 경우, 접수 시스템은 매우 높은 확률로 장애를 맞이할 것이다. 그리고 현장은 창구에 접근조차 못한 고객들로 아수라장이 될 것이고.
