규모가 큰 프로젝트 일수록 의사소통에 많은 비용이 든다는 것은 모두 공감하고 있는 사실일 것이다.

CBD 기반 컴포넌트 모델링을 예로 들면,
분석/설계자의 다양한 내공을 모두 수용하기란 어려운 관계로 표준화라는 미명아래 가이드라인을 제공하지만...결과는 참담하기 그지 없다.

분석/설계자와 아키텍트(혹은 방법론 담당자)간의 동상이몽 이랄까?
이럴바엔 컴포넌트 이론이고 뭐고, 설계 패턴이고 뭐고 최대한 단순화된 컴포넌트를 모델링하라고 가이드 하는 것이 혼란 스러운 의사소통으로 인해 발생하는 비용을 줄일 수 있는 트레이드-오프가 될 수도 있을 것이다.

이런 대담한 시도가 H은행 차세대에서 시행되고 있다.
표준전문을 기반으로 하여 컴포넌트의 파라미터와 리턴값이 Document 타입으로 고정되어 있으며 컴포넌트에 대한 인터페이스 클래스도 없다(추상화...필요 없음)

이런 단순화를 통해 얻을 수 있는 가장 큰 장점은 구현 시 기능에만 집중하여 개발할 수 있다는 것이다.(개발자는 창의적인 생각을 하지 마세요..)

그럼 단점은? 당연 분석/설계자를 무뇌아적 객체로 간주하여 획일화된 단순한 표준을 수용하도록 유도하는 발상이 아닐까...

분석/설계자의 창의성...(미안하지만 다른 프로젝트에서 펼쳐 주세요..)
우리 프로젝트에서는 프로세스 컴포넌트 1개 클래스, 엔티티 컴포넌트 1개 클래스만 설계 하시고요...이것이 여의치 않으면 엔티티 컴포넌트 간 호출도 가능합니다...순환 참조는 알아서 끊고요...

이것이 우리나라 금융 업계에서 적용되고 있는 CBD의 현실이다..

여기에서 더 나아가 도메인에 집중하여 설계 하자는 DDD(Domain Driven Design)나 관점을 서비스로 돌린 SOA에 대하여 논할 수 있을까? 너무 회의적인가...

빛나는 이론은 책장에 꽂힌 책 안에서만 유효하고 현실 프로젝트에서는 정글법칙만이 난무함을 인정해야 하는가?

선한 생각과 좋은 생각으로 승부할 수 있을것 같다. 굳이 좋지 않은 현실의 법칙들을 인정해가지 않으면서...