소프트웨어에서 아키텍처와 설계는 소프트웨어 개발이 원칙으로서 모든 복잡성과 함축성을 아직 완전히 이해하지 못하기 때문에 오랜 기간 동안 확정된 정의를 받아들이지 않았다. 하지만 이러한 주제에 대해 합리적인 논의를 이끌어내기 위해 어딘가에서 시작해야 한다. 이 기사 시리즈는 혁신적인 아키텍처 및 창발적 설계에 대해 관심이 있으므로 일부 정의, 고려사항 및 다른 기초 다지기로 이 시리즈를 시작하는 것이 이치에 맞을 것이다.

아키텍처 정의하기

소프트웨어에서 아키텍처는 개발자들이 씨름하는 가장 많이 논의되지만 아직 거의 이해하지 못한 개념 중 하나이다. 컨퍼런스에서 아키텍처에 대한 논의 및 같은 성향의 사람들의 모임이 많은 관심을 모으지만 여전히 모호한 정의만 내리고 있을 뿐이다. 아키텍처를 논의할 때, 일반적으로 애플리케이션 아키텍처 및 엔터프라이즈 아키텍처의 넓은 카테고리에 속하는 몇 가지 다르지만 관련된 관심사에 대해 논의하고 있는 것이다.

애플리케이션 아키텍처

애플리케이션 아키텍처는 애플리케이션을 구성하는 크게 나뉘어진 조각을 설명한다. 예를 들어, Java 영역에서 애플리케이션 아키텍처는 두 가지를 설명한다. 즉, 이는 특정 애플리케이션을 빌드하는 데 사용되는 프레임워크의 결합 — 필자는 프레임워크 레벨 아키텍처라고 부름 — 및 더 전통적인 관심사의 논리적 분리이며 필자는 애플리케이션 아키텍처 이름이라고 고집한다. 객체 지향 언어의 대부분의 실행자들은 개별 클래스가 재사용 메커니즘으로 잘 작동하지 않음을 발견하기 때문에 프레임워크 아키텍처를 구별로 나누는 것은 문제가 된다. (하나의 프로젝트에서 사용하기 위해 인터넷에서 하나의 클래스를 마지막으로 다운로드한 시간이 언제였는가?) 현대적인 객체 지향 언어에서 재사용의 단위는 프레임워크의 라이브러리이다. Java 언어와 같이 프레임워크가 풍부한 언어로 새 프로젝트를 시작할 때, 첫 번째 아키텍처적인 관심사 중 하나는 애플리케이션의 프레임워크 레벨 아키텍처이다. 재사용의 이 스타일은 Java 영역에 매우 깊게 침투하므로 필자는 객체 지향 언어로 Java 프로그래밍으로 참조하는 것을 중지하고 이를 프레임워크 지향 언어라고 해야 한다고 주장하기 시작했다. 다양한 방식으로 프레임워크 레벨 아키텍처는 실제 아키텍처를 표현하여, 이는 특정 빌딩 블록으로 설명된다.

애플리케이션 아키텍처의 다른 흥미로운 측면은 애플리케이션의 논리적 부분이 어떻게 함께 들어맞는지 설명한다. 이는 설계 패턴의 측면과 다른 구조적 설명이므로 둘 다 실제보다 더 추상적이고 논리적이 되는 경향이 있다. 예를 들어, 웹 애플리케이션이 논리적 배열을 달성하기 위해 어느 프레임워크를 사용하는지 지정하지 않고 Model-View-Presenter 패턴을 고수한다고 말할 수 있다. 이러한 논리적 배열은 애플리케이션의 새 부분에서 작업하기 시작하면서 작업 공간의 화이트보드를 장식할 가능성이 높은 것이다.

엔터프라이즈 아키텍처

엔터프라이즈 아키텍처는 엔터프라이즈가 전체적으로(대개 대규모 조직 내에서 실행 중인 애플리케이션을 의미함) 애플리케이션을 소모하는 방법에 대해 관심이 있다. 엔터프라이즈와 애플리케이션 아키텍처 사이의 관계에 대한 일반적인 유용한 메타포는 도시 계획에 대한 엔터프라이즈 및 빌딩 아키텍처에 대한 애플리케이션과 유사하다. 도시 계획자는 도시가 기능할 수 있도록 수도, 전기, 하수 및 기타 서비스의 공급에 대해 생각해야 한다. 수도 공급의 공유분을 초과하여 소모하는 하나의 빌딩을 가질 수 없다. 엔터프라이즈 아키텍처는 애플리케이션의 이러한 동일한 종류에 대해 심사숙고한다. 즉, 하나의 애플리케이션이 네트워크의 모든 대역폭을 소모하도록 허용할 수 없으며, 인프라 서비스가 고장나면 (가상) 하수가 백업한다.

엔터프라이즈 아키텍처는 서비스 지향 아키텍처(SOA)로 인해 최근 몇 년간 많은 주목을 받았다. SOA는 그 자체로 방대한 주제이므로 이 시리즈의 향후 기사에서 이를 특수 케이스로 다룰 것이다. 이는 애플리케이션 구성의 특성을 지시할 때 엔터프라이즈와 애플리케이션 아키텍처 사이의 선을 무너뜨리기 때문에 자체적으로 흥미로운 측면이 있다.

이전 단락은 이러한 중요한 개념의 피상적 정의를 제시했지만, 이는 다른 아키텍처로부터 수집한 몇 가지 정의를 포함하여 아키텍처의 더 흥미롭고 더 미묘한 정의에 대한 시작점으로 역할을 담당한다.

현존하는 정의

많은 똑똑한 사람들이 소프트웨어 아키텍처 정의를 시도해왔으므로, 필자는 어느 정도의 생각할 거리를 제공할 수 있을 것이다. Martin Fowler는 고전적인 백서인 "Who Needs an Architect?"(참고자료 참조)에서 몇 가지 정의를 논의한다. 그는 다음과 같이 Extreme Programming 메일링 목록에서 첫 번째 게시물을 인용한다.

"IEEE 정의를 털어버리는 RUP는 아키텍처를 '환경에서 시스템의 가장 높은 레벨 개념'으로 정의한다. '소프트웨어 시스템의 아키텍처(주어진 시간에)는 인터페이스, 더 작은 컴포넌트와 인터페이스로 구성되는 이러한 컴포넌트 등을 통해 상호 작용하는 중요한 컴포넌트의 조직 또는 구조이다.'"

이 정의는 필자가 위에서 설명한 애플리케이션 아키텍처의 영역에 잘 들어맞는다. 모호하지만, 아키텍처의 책임의 정수를 포착했으며, 이는 가장 높은 레벨 개념이다.

Fowler는 그 다음에 메일링 목록에서 응답하여 이전 정의를 논쟁한 Ralph Johnson을 인용한다.

"다음 정의가 더 나을 것이다. '가장 성공적인 소프트웨어 프로젝트에서 해당 프로젝트에 작업 중인 전문 개발자는 설계 시스템 설계의 이해를 공유한다. 이러한 공유된 이해를 "아키텍처"라고 한다. 이러한 이해는 시스템이 컴포넌트로 나뉘는 방법과 컴포넌트가 인터페이스를 통해 상호 작용하는 방법을 포함한다.'"

Johnson은 소프트웨어 개발이 기술보다 의사소통에 의존하고 있으며, 해당 아키텍처가 실제로 구체적으로 언어에 대한 어떠한 것이 아니라 시스템에 대한 공유된 지식을 표현하는 것을 훌륭하게 지적한다.

이전에 언급한 글에서 Fowler는 스스로 아키텍처의 가장 좋아하는 정의 중 하나를 다음과 같이 제시한다.

"아키텍처는 중요한 것에 대한 것이다. 그것이 무엇이든지 간에 말이다."

이는 적절하게 모호하긴 하지만 동시에 매우 설명적이다. 아키텍처 및 설계에 대한 많은 논쟁은 무엇이 중요한 것인가에 대한 오해와 관련하여 순환한다. 비즈니스 분석가에게 중요한 것은 엔터프라이즈 아키텍트에게 중요한 것과 다르다. 이러한 정의는 독자가 다른 것들을 정의하려고 시도할 수 있기 전에 환경 내에서 용어를 정의해야 함을 요약한다.

Fowler의 정의도 아키텍처와 같이 미묘한 어떤 것을 정의하는 것의 또 다른 중요한 측면을 강조한다. "중요한 것"은 개인과 그룹 사이에 달라질 뿐만 아니라 이러한 차이점은 실제로 상호간에 배타적일 수 있다. 예를 들어, 가상적으로 모든 SOA는 유연성과 속도 사이에 교환된다. 현재 사용 중인 오래된 클라이언트/서버 시스템은 거의 당연하게 이를 대체한 웹 기반, 포틀릿 엔진, 서비스 기반 버전보다 빠르다. 새 애플리케이션을 형편없는 개발자가 쓴 경우를 제외하고, 유연성을 제공하는 추가 계층은 사용자에 대한 응답 시간이 올라가서 느려지게 됨을 의미한다. 아마 아키텍트는 사용자에게 다음과 같이 말해야 된다. "아, 어쨌든 우리가 설치하고 있는 새로운 SOA는 훨씬 더 우수하게 작동하지만, 당신의 작업은 이제 훨씬 더 엉망이 될 것입니다. 미안합니다." 아마 바로 이러한 이유 때문에 개발자보다 아키텍트가 돈을 더 많이 버는 것 같다.

여기에서 아키텍처에 대한 필자가 좋아하는 정의가 남아있다.

"나중에 변경하기 어려운 것."

이러한 정의는 혁신적인 아키텍처의 개념에 가장 잘 맞는다. 혁신적인 아키텍처의 배후에 깔린 핵심적인 개념 중 하나는 의사결정을 가능한 한 늦게 미루는 것이며, 이는 최근에 보여준 경험이 더 우수하다는 대안을 대체할 수 있다. 이러한 아키텍처 스타일의 많은 빌딩 블록은 이 기사 시리즈의 전반에 걸쳐 나타나고 이 시리즈를 작성하는 동기가 되었다.

아키텍처의 논의를 끝내기 전에 필자가 "아키텍트" 직위를 논의하지 않으면 부주의하게 될 것이다. 우리는 너무 잘못 정의된 직위를 가진 산업에 종사하여 인사 부서를 힘들게 한다. 많은 조직들은 최고의 개발자를 승진시키려고 한다 — 이는 나중에 변경하기 어려운 것에 대한 중요한 의사결정을 내리는 사람이다 — 하지만 "아키텍트" 외에는 좋은 산업 용어가 없다. 일반적인 직무 설명이 존재하지 않으므로 모든 회사가 이 역할이 의미하는 바를 정의한다. 일부 아키텍트는 영화 Matrix의 2편의 끝에 나온 아키텍트와 유사하다(이는 Fowler가 Architectus Reloadus라고 분류함). 이러한 아키텍트들이 약 10년 전에 마지막으로 코드를 썼고, 이제 회사에 중요한 의사결정을 내리려고 한다. 이들이 유일하게 사용하는 소프트웨어 개발 도구는 Visio뿐이다.

대안 아키텍트 역할은 Fowler가 Architectus Oryzus(그의 동료 중 한 명인 David Rice를 따름)라고 지었다. 이러한 아키텍트는 프로젝트에 코드를 적극적으로 기여하며, 가장 어려운 부분에서 다른 개발자와 쌍을 이룬다. 이들의 책임도 다른 프로젝트 이해당사자와의 상호작용을 포함하여, 누구나 동일한 언어를 말하고, 동일한 정의를 사용하며 이해해야 하는 시스템의 부분을 이해하도록 한다. 명백하게 이러한 적극적인 역할은 혁신적 아키텍처의 목표를 현실화하는 데 중요하므로, 이 시리즈에서 반복적으로 다룰 것이다.

위로

설계 정의하기

대부분의 개발자들은 이미 설계에 대해 꽤 훌륭한 감각을 가지고 있으므로, 필자는 이를 정의하는 데 많은 시간을 낭비하지 않을 것이다. 이는 소프트웨어의 조각이 어떻게 함께 진행하는지에 대한 모든 세부사항을 표현한다. 이는 설계 패턴, 리팩토링, 프레임워크 및 기타 일상적인 개발자의 관심사 등 잘 다져진 영역을 포괄한다. 설계는 그림 1과 같이 크게 보면 BDUF(Big Design Up Front)와 Cowboy Hacking 사이 스펙트럼에 들어간다.

그림 1의 스펙트럼의 왼쪽에 소프트웨어를 개발할 때 나타나는 수많은 관심사를 모두 예상할 수 있음을 제안하고 이에 대한 응답을 제한하려고 노력한다. 다음 기사에서 이에 대해 더 많이 다룰 것이다. 필자가 설계를 정의하는 데 시간을 많이 낭비하지 않기 때문에 이에 대해 논의하는 데 시간을 낭비하지 않겠다는 것을 의미하지는 않는다. 이 시리즈의 많은 내용은 코드의 첫 행을 쓰기 전에 확정되어 설정하는 것이 아니라 개발하면서 설계가 떠오르도록 허용할 수 있는 방법의 다른 측면을 다룬다.

위로

아키텍처 및 설계 관심사

현재 아키텍처 및 설계의 정의에 대해 곧 작업하면서 필자는 관심사의 대단히 중요한 영역을 몇 가지 탐구해보려고 한다. 이러한 모든 주제는 기초적인 레벨에서 아키텍처와 설계 둘 다와 교차되므로, 이를 전면적으로 다루면 이 시리즈의 나중에 다시 참조할 수 있다. 먼저, 필자는 기술적 채무를 논의한 다음 복잡도와 마지막으로 만연한 일반성을 논의한다.

원금 및 이자

모든 개발자는 기술적 채무의 개념에 대해 인식하여, 여기에서 독자는 스케줄 압박과 같은 외부적인 강제를 위해 설계 측면에서 타협한다. 기술적 채무는 신용 카드 부채와 비슷하다. 즉, 해당 시점에 자금이 충분하지 않기 때문에 나중에 갚을 생각으로 자금을 빌려 쓴다. 이와 유사하게 프로젝트에서도 어떤 작업을 제대로 수행할 시간이 충분하지 않기 때문에 나중에 시간이 날 때 다시 고칠 계획으로 임시 방편을 적용한다. 불행하게도 많은 관리자들이 기술적 채무를 이해하는 것 같지 않기 때문에 과거의 작업을 재고하는 것에 대한 반대가 나타난다.

소프트웨어를 빌드하는 것은 도랑을 파는 것과 같지 않다. 도랑을 팔 때 타협을 하면, 너비가 똑바르지 않거나 깊이가 동일하지 않게 된다. 오늘 도랑에 결함이 있어도 내일 훌륭한 도랑을 파는 것을 방해하지 않는다. 하지만, 오늘날 빌드하는 소프트웨어는 내일 빌드하는 것의 기초이다. 편의를 위해 지금 타협하면 소프트웨어에서 엔트로피가 쌓이게 된다. The Pragmatic Programmer라는 책에서 Andy Hunt 및 Dave Thomas는 소프트웨어에서 엔트로피에 대해 논하고 엔트로피가 왜 해로운 영향을 주는지에 대해 논한다(참고자료 참조). 엔트로피는 복잡도의 측정값이며, 문제점에 JIT(Just-In-Time) 솔루션으로 인해 복잡도를 더하는 경우, 프로젝트의 잔존 수명에 어느 정도 대가를 지불해야 한다.

독자가 기존의 장기 실행 프로젝트에 새 기능을 추가하려 한다고 가정하자. 이러한 새 기능은 이에 특정한 내재된 복잡도가 있다. 하지만, 이미 기술적 채무가 있으면, 새 기능을 추가하기 위해 시스템의 이러한 타협한 부분을 해결해야 한다. 그러면 추가 사항의 비용이 재정적 메타포를 반영한다. 그림 2는 깔끔하게 설계된 시스템(예를 들어, 기술적 채무가 적거나 없는 경우) 새 기능을 추가하는 데 필요한 노력 대 기술적 채무가 많이 들어있는 일반적인 시스템 사이에 차이점을 보여준다.

고유의 복잡도를 원금으로서 생각하고 이전에 편리한 바로 가기로 부과된 추가 노력을 이자로 생각할 수 있다. 복잡도는 그 자체로 흥미로운 주제이다.

필수적 대 우발적 복잡도

소프트웨어에서 해결하는 문제점은 고유한 복잡도가 있으며, 필자는 이를 필수적 복잡도라고 한다. 기술적 채무를 초래한 타협으로 발생한 복잡도는 다르다. 이는 소프트웨어가 복잡해지는 외부적으로 부과된 모든 방법을 구성하여, 완벽한 세상에 존재하지 않을 것이다. 필자는 이를 우발적 복잡도라고 한다. 필자는 이러한 용어에 대해 필자의 책인 The Productive Programmer에서 정의하고 심도있게 논의한다(참고자료 참조). 이러한 용어는 일반적으로 단순히 미리 준비된 것이 아니다. 즉, 이는 설계와 같은 스펙트럼에 존재한다. 일부 예제는 이러한 구별을 분명하게 하는 데 도움을 줄 것이다.

필자의 동료 중 하나는 노조가 있는 회사의 급여 시스템에 대해 작업했다. 일부 구성원에 대해 노조가 안전하게 보호한 이권 중 하나는 사냥 시즌의 시작에 추가 휴일이었다. (이들은 훌륭한 협상자였을 것이다.) 문제가 되는 직원들은 하나의 공장에서만 일했지만 추가 휴일을 수용하는 것은 전체 회사의 급여 시스템의 합법적인 부분이었다. 이러한 변경은 소프트웨어에 많은 복잡도를 추가하였지만, 해결하는 비즈니스 문제의 일부였기 때문에 필수적 복잡도였다.

스펙트럼을 조금 더 따라가는 또 다른 예제는 항상 나타난다. 즉, 이는 입력 양식에서 필드 레벨 보안이다. 많은 사업가들은 각 필드의 보안 특성의 잘게 나뉘어진 제어를 원한다고 생각한다. 실제로 이들은 모든 해당 메타데이터를 정의하고 유지보수해야 하는 사용자에게 너무 부담을 야기하기 때문에 구현될 때에는 거의 항상 싫어한다. 여기의 프로젝트 중 하나에 속한 사업가들은 이 기능을 정말로 원했기 때문에, 이에 대한 화면 중 하나에서 이 중 일부를 구현했다. 그들이 이를 수행하기 위해 얼마나 많은 노력이 필요한지에 대해 직접 보면, 애플리케이션으로 유일한 액세스가 잠긴 사무실에서부터 온 것이기 때문에, 더 크게 나뉘어진 보안으로 진행할 수 있음을 결정하였다. 이는 비즈니스가 원한다고 생각한 것의 실제를 확인하면 창발하는 설계 의사결정의 훌륭한 예제이다.

우발적 복잡도를 향한 스펙트럼의 맨 끝에서 Enterprise JavaBeans(EJB) 기술의 처음 두 가지 버전과 같은 순수한 배관 경험과 BizTalk와 같은 도구가 있다. 몇 가지 프로젝트에 이러한 도구로 도입된 추가 오버헤드가 필요하지만, 이를 사용하는 프로젝트의 대부분에 복잡도를 추가할 뿐이다.

세 가지 사항이 우발적 복잡도를 야기하는 경향이 있다. 필자는 처음에 이를 이미 논의했다. 즉, 이는 스케줄 또는 다른 외부 압력으로 인해 코드하기 위해 JIT(Just-In-Time) 해킹한다. 두 번째는 중복 제거이며, Pragmatic Programmers가 DRY(Don't Repeat Yourself) 원칙의 위반을 호출하는 것이다. 중복 제거는 개발자가 인식조차 못한 상태에서 매우 많은 장소에 영향을 미치도록 관리하기 때문에 소프트웨어 개발에서 가장 서서히 퍼지면서 감소하는 강제 실행이다. 명백한 예제는 복사하여 붙이기 코드이지만, 더 정교한 예제가 많이 나타난다. 예를 들어, 객체 지향 맵핑 도구(예: Hibernate 또는 iBatis)를 사용하는 거의 모든 프로젝트에 중복 제거가 많이 있다는 것이다. 독자의 데이터베이스 스키마, XML 맵핑 파일 및 POJO의 지지는 다소 다르지만 겹치는 정보가 있다. 이러한 정보에 대한 규범적인 소스를 작성하고 다른 부분을 생성하여 이를 수정할 수 있다. 중복 제거는 구조적 변경을 만들거나 더 나은 코드를 향해 리팩토링하려는 시도를 막기 때문에 프로젝트에 해를 미친다. 세 가지 다른 장소에서 어떤 것을 변경하려 하는 것을 알면, 결과적으로 코드를 더 우수하게 만들지라도 이를 수행하는 것을 방지한다.

우발적 복잡도의 세 번째 동인은 비가역성이다. 되돌릴 수 없는 의사결정으로 인해 어느 정도 레벨의 우발적 복잡도가 나타날 것이다. 비록 비가역성의 영향이 아키텍처 레벨에서 둘 다 더 일반적이고 더 해롭다고 하더라도, 비가역성은 아키텍처와 설계 둘 다에 영향을 준다. 되돌리기에 불가능하거나 방해가 되는 의사결정을 방지하도록 노력하자. 필자의 일부 동료가 사용하는 주문 중 하나는 최종 책임 시점까지 대기하는 것이다. 이는 의사결정을 너무 오래 미뤄야 함을 의미하지 않고 딱 필요한 만큼만 미뤄야 함을 의미한다. 일부 아키텍처 관심사에 대해 의사결정할 수 있는 최종 책임 시점은 언제인가? 의사결정을 오래 미루면 미룰수록 독자가 사용 가능한 가능성이 더 많이 남아있다. 스스로 물어보자. "내가 지금 이러한 의사결정을 내려야 하는가?" 그리고 "의사결정을 미루기 위해 무엇을 할 수 있는가?" 독자가 의사결정 프로세스에 일부 정교함을 적용하면 나중까지 미룰 수 있는 것에 대해 놀라울 것이다.

프레임워크 레벨 아키텍처와 애플리케이션 아키텍처 사이에 이전에 나눈 구별은 최종 책임 시점의 원칙에 연결된다. 애플리케이션 아키텍처는 논리적 아키텍처가 되려는 경향이 있다. 예를 들어, 독자가 Model-View-Presenter의 관심사의 분리를 원하는 것을 알고 있다고 가정하자. 많은 경우에 일부 또는 모든 요구사항에 부합하는 프레임워크를 선택하여 논리적 아키텍처의 실제 구현방식으로 도약하게 된다. 실제 구현방식을 한 번 배치하면 의사결정을 미룰 수 있는지 살펴보자. 이는 고려해야 하는 다른 종류의 의사결정을 제한한다. 프레임워크 의사결정을 가능한 한 미루면 실제로 덜 오염된 더 나은 옵션이 사용 가능하게 남아있다.

만연한 일반성

아키텍처 및 설계에 대한 가장 중대한 마지막 관심사는 필자가 만연한 일반성이라는 구절로 이름을 붙였다. Java 영역에서 병이 있는 것처럼 보인다. 즉, 이는 가능한 한 제네릭으로 만들기 위해 노력하여 솔루션을 과도하게 엔지니어링 하는 것이다. 이에 대한 동기는 명백하다. 즉, 확장을 위해 많은 계층에서 빌드하는 경우, 나중에 더 간편하게 더 많이 빌드할 수 있다. 하지만, 이는 위험한 덫이다. 일반성은 엔트로피를 추가하기 때문에, 초기 프로젝트에서 흥미로운 방법으로 설계가 진화하는 기능을 손상시킨다. 유연성을 너무 많이 추가하면 코드 기반에 대한 모든 변경이 더 복잡하게 된다.

물론, 확장 가능성을 무시할 수 없다. 애자일 이동은 기능을 구현하기 위한 의사결정 프로세스를 요약하는 훌륭한 구절이 있다. 즉, 이는 YAGNI(You Ain't Gonna Need It)이다. 이는 간단한 기능을 과도하게 엔지니어링하는 것을 방지하기 위해 시도하는 주문이다. 이제 필요한 것을 정확히 구현하자. 그리고 나중에 더 필요하면 추가할 수 있다. 필자는 아키텍처 및 설계 둘 다에서 타협으로 너무 거대해진 일부 Java 프로젝트가 해당 프로젝트가 실패한 일반성과 확장 가능성의 제단에서 만들어졌음을 확인했다. 이는 수명을 가능한 줄여서 프로젝트가 생존하기 위해 계획하기 때문에 당연히 반어적이다. 확장 가능성과 과도한 엔지니어링 사이에 명확한 선을 탐색하는 방법을 배우는 것은 어렵다. 이는 필자가 자주 다시 언급할 주제이다.

위로

로드맵

이 기사는 좋은 인상을 주는 말이 많이 들어있고 소스 코드가 없으며, 이 점에서 이 시리즈의 다른 모든 향후 기사와는 다르다. 아키텍처 및 설계와 같은 복잡한 주제를 토론하는 면에서 내재적인 문제점 중 하나는 누구나 동일한 페이지에 존재하도록 나타나야 하는 컨텍스트 설정이다. 필자는 이 시리즈의 나머지 파트에 단계를 설정했으며, 여기에서 혁신적 아키텍처와 창발적 설계와 관련된 특화된 영역을 탐구할 것이다. 각 기사는 많은 세부사항 및 소스 코드로 이러한 개념 중 하나 또는 둘 다의 설명적인 특정 측면을 깊이 탐구할 것이다. Next up: 필자는 테스트 구동형 개발을 통한 창발적 설계에 대해 논의하며, 여기에서 필자는 테스트 구동형 설계라고 이름을 바꾸었다.

참고자료

교육

• "Who Needs an Architect?"(Martin Fowler저, IEEE Software, 2003년 9월): Fowler의 고전적 백서를 읽어보자.
  
  
• The Productive Programmer(Neal Ford저, O'Reilly Media, 2008년): Neal Ford의 가장 최신 저서에서 이 기사의 다양한 주제에 대해 확장한다.
  
  
• The Pragmatic Programmer(Andy Hunt 및 Dave Thomas저, The Pragmatic Bookshelf, 2001년): 이 책에서는 소프트웨어에 대한 엔트로피의 영향을 토론한다.
  
  
• Essential XP: Emergent Design(Ron Jeffries저): 고도의 프로그래밍 영역에서 창발적 설계 고려사항의 웹 논의.
  
  
• "Emergent Optimization in Test Driven Design"(Michael Feathers저): 테스팅이 미성숙한 최적화를 방지하는 데 도움을 주는 방법.
  
  
• 기술 서점에서 다양한 기술 주제와 관련된 서적을 살펴보자.
  
  
• developerWorks Java 기술 영역: Java 프로그래밍과 관련된 모든 주제를 다루는 여러 편의 기사를 찾아보자.
  
  

토론

• developerWorks 포럼 & 블로그를 통해 developerWorks 커뮤니티에 참여하자.
  
  

필자소개

Neal Ford는 글로벌 IT 컨설팅 업체인 ThoughtWorks의 소프트웨어 아키텍트이자 Meme Wrangler이다. 애플리케이션, 교육용 자료, 매거진 기사 및 비디오/DVD 프리젠테이션을 설계 및 개발하며 다양한 기술과 관련된 서적의 저자 또는 편집자이기도 하다. 최근에 출판된 책으로는 The Productive Programmer가 있다. 대규모 엔터프라이즈 애플리케이션의 설계 및 빌드에 많은 관심을 가지고 있는 그는 전세계의 개발자 컨퍼런스에서 국제적으로 인정 받고 있는 연사로도 활동하고 있다. 그의 웹 사이트를 살펴보자.

아티클 순위

의견

위로

목차

• 아키텍처 정의하기
• 설계 정의하기
• 아키텍처 및 설계 관심사
• 로드맵
• 참고자료
• 필자소개
• 의견