소프트웨어 개발을 실제 환경에서 잘 분리하여 모델링 하는 과정을 거쳐 논리에 따라 개발하는것은 매우 많은 장점들이 있다.

우선, 요구사항의 모순들을 찾을 수 있다. 요구사항이 ‘전산화’ 과정에 있는 것 일수도 있지만, 많은 경우에 요구사항의 실체가 개발된 소프트웨어를 통해 들어난다. 그래서 제일 구체적인것이 소프트웨어 개발 중에 나타나게 되는데, 실제 개발을 위한 모델링 과정중에서 논리적 모순이 많이 발견되곤 한다. - 때때로, 기획이나 UI는 발로 하냐라는 개발자들의 원성이 있기는 하지만, 사실 나는 실체화된 도메인로직이 없는한 나타날 수 밖에 없는 개발의 한 과정이라고 생각한다.

또한, 잘 조직된 모델은, 변경사항에 대해서도 강한 적응력을 보인다. - 완전히 새로운 모델링이 필요한 상황이 아니라면 모델링 할 때 좀더 확정성 있게 모델링 하는것이 보편적이며, 요구사항이 현재의 모델과 너무 안맞으면, 모델을 바꿔야하는건지 등에대한 의견을 교환 할 수도 있다.

그런데, 논리에 맞춰 개발하다 보면, 만들어진 논리에 갖히는 경우가 종종 있다. 그래서 만일 모델링에서 놓친 정보들이 있다면 구현시에 조금씩 조건들을 추가하여 모델을 수정하는데, 이때 만일 모델이 너무 거대하거나 복잡하고, 실제 요구사항에서의 추상화 레벨이 높다면, 어정쩡하게 수정되는 경우가 많다.

TL;DR

(TL;DR이라는 용어를 알게 된 후 너무 자주 써 먹는 경향이 있으나.. 역시 이번에도 결론은 TL;DR 형태로…)

• 전체적으로 요구사항을 논리에 맞게 모델링을 하자
• 모델링의 추상화 단계를 너무 높게 하지 말고 핵심적인 것만 하자 (아주 구체적인 내용은 구현단에 위임)