
둘 중 하나를 선택해야 한다면. 대부분의 사람들은 해야 될 가장 중요한 것을 선택합니다. 하지만,설계(소프트웨어 또는 다른 것들)에서는 그렇지 않습니다. 두 가지 선택사항의 존재는 당신이 설계 시 불확실성을 고려할 필요가 있다는 것은 알려주는 지표(indicator)입니다.
불확실성을 가능한 마지막 순간에 설계에 자세한 부분(defer commitment[1])을 결정할지, 설계 결정들의 중요성을 감소시키기 위해 분할하고 추상화할지 결정하는 기준으로 이용하십시오. 만약 당신의 마음을 첫 번째(가능한 나중에 결정하는 것 – defer commitment)에 고정시킨다면 이 첫 번째 원칙에 갇히고 종속될 수 있습니다. 그 결과 부수적인 결정이 굉장히 중요해 지고 소프트웨어의 유연성이 줄어듭니다..
아키텍쳐에 있어서 가장 간단하고 구조적인 정의중 하나는 Grady Booch의 말에서 인용됩니다.
“모든 아키텍쳐는 설계지만 모든 설계가 아키텍쳐는 아니다. 아키텍쳐는 시스템을 구체화하는 중요한 설계 결정들을 나타낸다. 여기서 중요한 것은 변화의 비용에 의해서 측정된다.”
이 정의에 따르면 효과적인 아키텍쳐는 일반적으로 설계 결정의 중요성을 감소시키는 것입니다. 비효율적인 아키텍쳐는 설계 결정의 중요성을 확대시킵니다. 설계 결정이 합리적으로 두 가지 방법 중 하나로 진행될 수 있다면, 아키텍트는 한 걸음 물러설 필요가 있습니다.
굳이 이 분이 누군지 말 안해도 다들 아실겁니다. 🙂 바로 Grady Booch 입니다. UML을 탄생시킨 3인방 중에 한명이며, 지금의 소프트웨어 공학에 지대한 영향을 끼치신 분이죠 .
Grady Booch의 끊임없는 지적 호기심을 보여주는 좋은 사이트가 있어서 소개합니다.
바로 Handbook of Software Architecture 라는 사이트 입니다. 아마 아실 분은 다 아시겠죠 :). 여기에 Pattern들에 대한 보물이 숨겨져 있습니다.
바로 지구상에 발표된 패턴들을 잘 요약해 놓고, 적절하게 다양한 관점으로 분류하고 잘 요약정리해 놓았습니다. 단순히 GoF, POSA, PLoP 에 나온 분류 보다 훨씬 자세하게 잘 분류되어 있고, 지구상에 많은 패턴을 끊임없이 요약 정리하고 계시다니.. 대단하시네요. 저도 나름대로 분류 작업을 진행해야 겠네요 🙂