[Angular Architecture] 애플리케이션 구조 설계 - 1

Angular 프로젝트를 위한 구조 설계 요건에 대해 알아본다.

- 프레임워크 선택 고려 사항

- 개발 생산성과 유지 보수성을 높일 수 있는 방안

- 참조 문서와 소스

+ Angular Enterprise Architecture pattern 문서

+ 해당 문서의 예제 소스

프레임워크 선택 고려 사항

프레임워크는 잘 정돈된 놀이터와 같아 기구를 타고 놀면 된다. 하지만 라이브러리의 경우는 툴박스와 같아서 박스안에는 망치, 드라이버, 못같은 것만 있다. 그럼 놀 것을 어떻게 만들지는 도구를 사용하는 사용자의 몫이다. 현재 UI 프레임워크/라이브러리는 Angular, React, Vue 등이고 풀스택으로는 Meteor를 선택해서 사용하고 있다. Angular 프레임워크와 React UI 라이브러리 또는 Meteor 선택시 고려사항을 개인의견으로 간략히 정리한다.

Angular Framework

- 대규모 협업 팀에 유리: 대략 10명이상으로 HTML Publisher와 Javascript 개발자가 분리되어 있을 경우

- JQuery가 low level의 javascript로 개발해 오던 개발자들이 접근하기에 수월하다고 판단함

- Typescript, RxJS 반드시 알아야 한다.

React Library

- HTML Publisher와 Javascript 개발을 같이하는 스타트업 또는 프론앤드 개발자에게 유리

- 원하는 것들을 선택해 적용할 수 있다.

Meteor

- FullStack 으로서 javascript가지고 전부 개발하고 싶을 경우

- 아이디어를 빠르게 구현하고 검증 받고 싶을 경우

- UI는 Angular, React, Vue 등으로 선택해 사용할 수 있으나, React가 적합하다 판단

그러나 어떤 것을 선택하든 공통적으로 고려해야 하는 사항으로 애플리케이션 아키텍쳐이다. 이에 대한 좋은 영상이 있어 보기를 권한다.

애플리케이션 아키텍쳐

위의 영상을 정리해 보면 다음과 같다.

- Layered Architecture 구성

- 역할 분담

+ Module: 업무 최소 단위, 하나를 제거해도 다른 것에 영향을 주지 않는 단위, Module은 Sandbox만 알뿐이다.

+ Sandbox: Module은 Sandbox를 통해 Application Core나 Base Library를 접근한다.

- 일관성을 유지시킴

- 시큐리티 가드 역할

- 공통 Interface 역할

+ Application Core: Module을 관리(Control) 한다.

- Module의 Life Cycle을 담당한다.

- Module 간 통신을 담당한다 (inter-module communication)

- Module을 직접 가져다 쓰지 않고, Sandbox의 공통 API를 통해 명령을 내리고, 듣는다.

- General error handling

- Extension을 통해 Application core기능을 확장한다.

+ Extension 확장

- Error handling

- Ajax communication: 공통 Format (request/response) 통신, 서버 오류 관리

- New module capabilities

- General Utils

- What you want

+ Base Library

- 개발자들이 직접 base library를 건드리게 하지 말자. 나중에 바뀔 수 있다.

- Browser normalization

- General purpose utilities: Paser/serializer, Object / DOM manipulation, Ajax Communication

- low-level extension 제공: application extension처럼 base library를 확장한 것들을 제공한다.

정리

- Base Library만이 사용중인 브라우저를 알고 있다. 아키텍쳐의 다른 layer에서 알 필요가 없다.

- Application Core만이 사용중인 Base Library를 알고 있다. 아키텍쳐의 다른 layer에서 알 필요가 없다.

- Module은 Sandbox의 존재외에는 아무것도 모른다. 아키텍쳐의 나머지에 대해선 아무것도 모른다.

장점

- 하나의 프레임워크상에서 서로 다른 멀티 애플리케이션을 만들 수 있다. 즉, 기존의 컴포넌트를 재사용함으로서 시간을 줄일 수 있다.

- 느슨한 연결(loose coupling)으로 인해 모듈 단위 테스트가 가능해짐.

- 확장 가능한 자바스크립트 아키텍쳐는 하나의 블록을 교체한다고 해도 두려워 할 필요가 없는 상태가 되어야 한다. 즉, 이를 달성할 수 있다.

유지 보수성 높이기

유지보수가 좋은 코드는 다음의 특성을 갖는다.

- 직관적이다. Intuitive

- 코드 이해가 쉽다 Understable

- 적용하기 쉽다 Adaptable

- 확장하기 쉽다 Extendable

- 디버깅하기 쉽다 Debuggable

이를 위해 해야할 것들.

- Code Style, Code Convention 지키기

- Naming 잘 하기: 이름에 대한 길이에 대해 걱정하지 말자.

- Javascript에서 css 핸들링 하지 말자

- event object를 바로 다른 function의 argument로 넘기지 말고, 필요한 정보만을 준다.

- 사용전 object undefined 체크

- string 값들은 별도의 Config Data 객체에 담아서 사용한다.

- 빌드 자동화 하자

from http://mobicon.tistory.com/565 by ccl(A) rewrite - 2020-03-06 23:54:53