BLOG main image
분류 전체보기 (344)
NWC Consulting (1)
서비스 (173)
출판 (169)
일반 (0)
195,318 Visitors up to today!
Today 34 hit, Yesterday 86 hit
daisy rss
2013.04.18 10:17

좋은 것으로 타고난 아키텍처는 없다. 좋은 것으로 평가된 아키텍처가 있을 뿐이다. 특별한 목적에 적합한 것으로 평가된 것이 좋은 아키텍처인 것이다.

그렇다고 아키텍처를 설계할 때 따라야할 규칙이 없는 것은 아니다. 이들 규칙을 적용하는데 실패했다고 해서 자동적으로 아키텍처가 결함을 갖는 다는 것을 의미하지는 않지만, 적어도 좀 더 주의깊게 살펴보라는 경고 신호로서 받아들여야 한다.

 

우리는 다음과 같은 프로세스를 추천한다.

1. 아키텍처는 인정된 기술 리더와 함께하는 한 아키텍처 또는 아키텍처들의 조그만 그룹에서 만들어낸 것이어야 한다. 이렇게 함으로 아키텍트와 개발 팀 사이에 강력한 연결을 가능하게 한다.

2. 아키텍트나 아키텍처 팀은 잘 명세되고, 우선순위가 작성된 품질 속성 요구사항에 기반해야 한다. 이렇게 함으로 개발 지연과 같은 상황에 트레이드 오프(tradeoffs)로 대응할 수 있게 한다.

3. 아키텍처는 뷰를 사용해서 문서화해야 한다. 뷰들은 프로젝트 생애주기 동안의 중요한 대부분의 이해관계자들의 관심사(concerns)를 다루어야 한다. 최소한의 문서로 시작해서 점점 더 정교하게 작성한다. 관심사는 일반적으로 시스템의 구축, 분석, 유지보수, 새로운 이해관계자에 대한 교육과 같은 것과 관련된다.

4. 아키텍처는 시스템의 중요한 품질속성을 만족시킬 수 있는가로 평가해야 한다.

5. 아키텍처는 점진적으로 구현해야 한다. 이렇게 하는 한 가지 방법은 뼈대가 되는 시스템을 만드는 것이다. 커뮤니케이션 경로는 실행되지만 최소의 기능을 갖고 시작하는 것이다. 뼈대가 되는 시스템은 점진적으로 자라게된다. 이때 리팩토링은 필수적이다.

위의 내용을 명령형으로 바꾸어 봤다.

아키텍처 팀과 개발 팀 사이에 강력한 연결을 만들어라.  트레이드 오프로 대응할 수 있도록 품질 속성 요구사항에 우선순위를 작성하고 그것에 기반으로 작업하라. 뷰를 사용해서 문서화하라. 시스템의 중요한 품질속성을 기준으로 평가하라. 뼈대가 되는 시스템을 만들고 점진적으로 구현하라.  

우리는 다음과 같은 구조적 규칙들을 제시한다.

1. 아키텍처는 잘 정의된 모듈들이 특징이 되어야 한다. 모듈의 기능적 책임이 정보 은닉과 관심사 분리의 원리에 의해 할당되어져야 한다.

정보 은닉된 모듈들은 캡슐화해야 한다. 캡슐화를 통해 변화의 파급효과를 차단할 수 있다.

각각의 모듈은 잘 정의된 인터페이스를 가져야 한다. 이들 인터페이스는 개발팀들이 관련된 서로의 팀에 독립적이도록 해야 한다.

2. 여러분의 요구사항이 전례가 없는 것이 아니라면, 여러분의 품질 속성은 잘 알려진 아키텍처 패턴들이나 전술들을 사용해서 달성될 수 있도록 해야 한다.

3. 아키텍처는 상업용 제품이나 도구의 특별한 버전에 의존해서는 안된다.

4. 데이터를 생성하는 모듈은 데이터를 소비하는 모듈과 분리해야 한다.

5. 모듈과 컴포넌트 사이에 일대일 대응을 기대하지 마라.

6. 프로세스를 특별한 프로세서에 쉽게 할당하도록 작성해야 한다. 심지어 런타임에서도.

7. 컴포넌트가 상호작용하는 방법이 적은 것이 특징이 되어야 한다. 시스템은 전체적으로 같은 방법으로 같은 일을 할 수 있도록 해야 한다. 이렇게 함으로 이해도를 높이고 개발 시간을 줄이고 신뢰성을 증대하고 수정가능성을향상 시킨다.

8, 아키텍처는 구체적이고 작은 자원 경쟁 영역들(resource contention areas)을 포함해야 한다. 경쟁에 대한 해결책이 분명히 명시되고, 관리되어야 한다.

예를 들어, 만약 관심사 영역이 네트워크 이용이라면, 아키텍트는 네트워크 트래픽을 최소화하도록 강제하는 개발 팀 지침을 만들어야 한다.

위의 내용을 명령형으로 바꾸어 봤다.

기능적 책임이 정보 은닉과 관심사 분리 원리에 의해 할당되도록 모듈화하라. 모듈은 캡슐화하라. 모듈은 잘 정의된 인터페이스를 갖도록 해라. 아키텍처 패턴이나 전술을 사용하라. 상업용 제품이나 도구의 특별한 버전에 의존하지 않도록 해라. 데이터를 생성하는 모듈과 소비하는 모듈을 분리하라. 모듈과 컴포넌트 사이의 일대일 대응을 기대하지 말라. 프로세스는 프로세서에 쉽게 할당하도록 작성하라. 컴포넌트들 사이의 상호작용에 일관성이 있게 하라. 자원 경쟁이 최소한으로 일어나도록 하라.




 

 

 

 

 

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret

티스토리 툴바