[SA강좌] Part 1-19 아키텍처가 바라보는 View

내가 예전에 만들었던 소프트웨어에 이런 것이 있었다.

AutoCad에 애드인하는 소프트웨어 였는데. 건축설계사무소에서 Cad에 설계를 할때에 정의된 클립아트 형태 ( 계단, 지붕, 문 등등 )를 사용해서 아파트나 주유소와 같은 건축물을 설계하면 관련 클립아트들이 컴포넌트 형태로 건축 일위대가라는 속성과 연결되어져서 실제 건축에서 산정되는 단가를 추출해주는 프로그램이었다.

건축가의 처음 '투시도'하나에서… 실제 '건축내역서'까지 파생되는 과정을 보면, 현재의 소프트웨어의 구상과 참으로 유사한듯 하다.

아마도, 완성된 프로그램을 빠르게 도식화해서 '고객'과 협의에 사용하게 하는 프로그램이 만들어진다면, 정말 괜찮을 듯 하다.

말이 조금 빗나갔지만, 아키텍쳐를 바라보는 View에 따라서 다 다르다.

업무관점에서 바라봤을때에..

구성	내용
애플리케이션 프레임워크 레이어	기술 기반 기능을 제공한다.
애플리케이션 프레임워크 레이어	업무 기반 기능을 제공한다.
업부 파티션 레이어	실제 업무 기능을 제공한다. 공통 업무 기능을 제공하는 코어 업무 파티션과 나머지 일반 업무 기능을 제공하는 단위 업무 파티션으로 나눌 수 있다.

구현관점에서 바라봤을때에..

구성	내용
프리젠테이션 레이어	뷰(View). 액터-시스템 인터페이스를 제공한다. 채널계 쪽으로 빠질 수도 있다.
애플리케이션 레이어	프리젠테이션 레이어와 비즈니스 레이어를 연결한다. 외부 시스템으로부터 요청을 받아들인다.
비즈니스 레이어	컨트롤(Control). 제공해야 하는 서비스를 실행한다.
커넥터레이어	다른 레이어를 리소스 레이어나 외부 시스템과 연결한다.
업부 파티션 레이어	모델(Model). 시스템이 다루는 정보를 관리한다.

시스템 관점에서 바라왔을때에.. 모든 시야에 따라서 그 레이어는 달라지게 된다.

네번째로 기술적으로 균일하게 만들 수 없다는 것을 알아야 한다.

다양한 기술과 다양한 개발자들과 일해야 하기 때문에, 그 기술 구조와 업무 구조에 따른 형태를 잘 구상해야 한다. 특히나 사업관리와 잘 이야기해야 할 것이 유지보수도 쉽고, 인력 수급도 쉽고, 개발 난이도도 낮은 수준의 시스템을 그리라는 것이다.

목표치를 조금은 낮추어 잡아야 프로젝트의 성공확률이 높아진다.

그리고, 개발언어, 툴에 너무 끌려다니면 안된다. 그래서, 구현을 생각하지 말고 생각해야 한다. 단순 CRUD성 프로그램을 만들기 위해서 복잡한 아키텍쳐를 구사할 필요가 없다.

가능하면 자동 코드 생성이 되는 툴을 사용하라.

다섯째로 일은 사람이 한다는 점.

이야기 많이 하고 술 같이 많이 마시고, 담배피고.. 결국 머리가 희게된다..ㅡ.ㅡ;

사람과의 관계가 가장 중요하게 된다는 점이다.