서비스 시스템의 목표

아키텍트는 소프트웨어 복잡도를 해결하면서 시스템의 품질 속성을 획득해야 한다. 이 서비스 시템은 물론 변경도 용이해야 한다.

유지보수성, 확장성, 재구조화성, 이식성을 가져야 한다는 점이기도 한다.

• 소프트웨어 복잡도 해결
• 시스템의 품질 속성 획득
  • 변경용이성
    • 유지보수성, 확장성, 재구조화성, 이식성
  • 상호운영성
  • 효율성
  • 안정성
    • 고장 감내, 강건성
  • 시험요잉성
  • 재사용성
• 문제를 해결하기 위한 기본 테크닉들
  • 추상화, 캡슐화, 정보은폐, 모듈화, 고려사항의 분리, 결합력과 응집력,
  • 충분-완전-원시성, 정책과 구현의 분리, 인터페이스와 구현의 분리, 한번의 참조, 분할 정복

그러나, 아키텍트들이 주의하여야할 점들이 있다.

가장 훌룡한 아키텍쳐는 목표시스템과 어울려야 한다는 것이다.

그렇다면. 반문할 수 있다. 어떤 아키텍쳐가 최선의 아키텍쳐냐고? 당근, 답변은 없다.

'그때 그때 달라요'

이런 예를 들어보자, 정말 엄청나게 짧은 기간에 대량의 데이터를 읽어서 실시간으로 레포트를 출력하는 프로그램을 만드는데 조직원들의 구성도 초보개발자들로 구성되어 있는데다가, PM도 성질을 부리고 고객도 성깔깨나 있는 곳이라면 어떻게 할것인가?

더군다나, 한 보고서 출력시 1초를 넘기면 안된다고 성질을 부리고 있다면?

물론, 아주 멋진 아키텍쳐를 제안해서 만들고 싶다.

AJAX로 화면을 구성하고 Spring Object로 비즈니스 컨테이너를 사용하고 하이버네이트로 OR맵핑을 한 아주 멋진 구성을 들이민다면?

아마도, 개발자들이 나자빠질것이다.

차라리.. 4GL도구나 레포팅 툴을 사용하십시요. 라고 제안을 하는 것이 올바른 아키텍트이다.

또하나의 주의점은 가이드라인이나 아키텍쳐라는 것 자체가 개발자들이 보기에는 무시무시하고 배우기 싫고. 귀찮은 부분이라는 점이다. 아마도, 개발을 진행하면서 무수히 많은 도전을 받을 것이기 때문에. 인내심과 이해관계자들을 설득하려는 뛰어난 구강신공을 가지는 것이 좋다.

아니면, 아예.. 고객을 설득해라!

심플하고 반복하지 않는 것!

이올린에 북마크하기

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.