Fundamentals of Software Architecture

저자 정보

Mark Richards & Neal Ford

topics

• architecture patterns
  • technial basis
• components
  • identification, coupling, cohesion, partitioning, granularity
• soft skills
  • team management, meetings, negotiation, presentations, and more
• modernity
  • engineering practices and operational approaches
• discipline
  • repeatable results, metrics, and concrete valuations

code examples
http://fundamentalsofsoftwarearchitecture.com

questions
bookquestions@oreilly.com

TOC

defining software architecture

여러 정의가 존재한다.

• blueprint of the system
• roadmap for developing a system
• structure + characteristics

Architecture Characteristics

system의 criteria이며 보통 system 기능에 대한 orthogonality이다.

• availability, reliability, testability, scalability, security, agility, fault tolerance
• elasticity, recoverability, performance, deployability, learnability

architecture를 설계할때 발생 가능한 "결정" 들이 variance이다.

design principles

hard-and-fast rule이라기 보다는 guideline이다.
예를 들어,

• microservice architecture에서 성능 향상을 위해 service간 asynchronous message를 사용하는 경우
  • 선호되는 방식에 대해 guide 하는 것이 guideline이다. 이 경우 asynchronous messaging을 선호
  • 이로서 개발자는 이와 관련된 적절한 protocol을 선택한다. (REST or gRPC)

expectations of an architect

architect?
expert programmer 부터 전략적 기술 결정자일 수 있다.

architect로부터 기대되는 역할은 다음과 같다.

• architecture decision들을 결정
  • decision을 내리고, principle을 정의하여 조직에서 사용할 수 있게 함
  • 기술적 specify 이전에 architect는 guide를 내려야 함
    • ex. React.js를 frontend에서 사용할지 말지에 대한 결정 (이 경우는 technical 결정임)
    • architect는 team에 frontend web 개발에서의 reactive-based framework을 사용할 수 있도록 가르켜야 함
    • 이후 개발팀이 Angular를 쓸지 Elm을 쓸지 React.js, Vue 등을 쓸지 가이드
• architecture의 지속적 분석
  • 최신 기술과 현재 기술에 대한 분석 및 이를 적용하여 개선할 수 있는 점을 찾아야 함
• 최신 trend의 반영
  • 최신의 기술 trend 반영
• 결정에 대해 compliance를 보장
  • 개발 팀이 architecture decision들과 principle들을 제대로 따랐는지를 확인해야 함
• 노출과 경험의 다양화
  • 다양한 기술, frameworks, platforms, 환경에 노출되어야 함
• 사람 다루는 기술
  • teamwork, faciliation, leadership등을 갖춰야 함
• 정치에 대한 이해/navigate
  • 정치적 climate를 이해해야 하고 이 방향에 맞게 나갈수 있도록 이끌어야 함(navigate)

Intersection of Architecture and ...

Laws of Software Architecture

• Everything is a trade-off
  • trade-off가 아닌 것을 발견했다면, 이는 trade-off를 아직 발견하지 못한 것이다.
• how 보다 why가 더욱 중요하다.

Foundations

architecture에서의 중요한 tradce-offs
개발자들은 component, modularity, couping, connascence등에 대해 이해해야 한다.

Architectural Thinking

단지 architecture에 대해 생각하는 것이 아니라, architect는 개발자와 다른 관점으로 관찰해야 한다.

1. architecture와 design의 차이를 이해해야 한다.
   architecture work에 대해 개발 팀과 협업해야 한다.
2. 기술적으로 다양하게 알아야 한다.
   다양한 가능성을 파악할 수 있어야 한다.
3. trade-off에 대해 이해하고, 분석하고 조화하는 것이다.
4. business driver의 중요성을 이해하고 architectural concern에 녹여야 한다.

Architecture versus design

전통적인 architect의 역할

1. business 요구사항을 분석하고
2. architectural characteristics(such as scalability, performance, and availability)를 정의
3. architecture pattern과 style의 선택
4. component 생성 (building blocks)

여기서 artifact들이 생성되고 개발자들에게 넘어간다.
개발자는

• 각 component에 대한 class diagram 작성
• user interface 화면 작성
• 개발 및 test

위 model은 boundary(barrier)가 확실하여, architecture와 design간 전파 되지 못하는 부분들이 존재하게 된다.

사실 architect와 developer들은 양방향으로 연결되어 서로 간에 feedback을 주고 받으며 갱신 되어야 한다.
여기서 architect는 개발자를 이끌어야 하며, "모니터링"도 수행해야 한다.

Analyzing Trade-offs

architect의 가장 중요한 일은 모든 솔루션, 기술적 내용, 기타 등등에 대한 trade-off를 살피는 것이다.
즉, 모든 solution은 "상황에 따라"로 결정된다.

• business drivers, company culture, budgets, timeframes, developer skill set, deployment environment 등 고려할 사항들이 많다.

Modularity

architecture에서 나오는 말들 중 95%는 modularity에 대한 것이고, 나머지는 이것을 어떻게 달성하냐에 대한 것이다.
이는 전적으로 복잡도를 낮추는 것이다.

modularity: a logical grouping of related code

• a grup of classes or functions
• package, namespace
• Measuring Modularity

1. cohesion

   • 연관된 것들이 한 곳에 모여 있어야 함

   • ex. 함께 package 되는 단위

   • 단위

     • functional cohesion: 모듈들이 연관되어 있음
     • sequential cohesion: 두 모듈이 interact
     • communicational cohesion: communication chain을 형성
     • procedural cohesion: 두 모듈이 특정 순서로 code를 실행해야함
     • temporal cohesion: timing에 의해 의존이 발생
     • logical cohesion: 기능적으로 연관은 없으나 논리적으로 연관됨
     • coincidental cohesion: 관련이 없는데 같은 source file에 있음 (negative form임)

     Cyclomatic Complexity
     LCOM (Chidamber and Kemerer Lack of Cohesion in Methods)
     The sum of sets of methods not shared via sharing fields

2. coupling
   afferent and efferent coupling

   • afferent coupling
     • number of incoming connections to a code artifact(component, class, function, and so on)
   • efferent coupling
     • outgoing connections to other code artifacts

Abstractness, Instability, & distance from the main sequence

• by Uncle Bob
• abstractness: ratio of abstract artifacts (abs class, interface class, etc) to concrete artifacts
• instability
  • effernt coupling to the sum of both efferent and afferent coupling
  • determines the volatiity of a code base
• distance from the main sequence
  • D = | A + I - 1|
  • ideal relationship between abstractness and instability
  • the closer to the line, the better balanced the class

3. connascence (두 개 이상이 동시에 탄생)

한쪽의 변경이 다른 쪽의 변경을 야기한다면 이 둘은 connascent이다.

static conascence
Dynamic connascence

cf. nascense (초기, 태어나려함, 발생, 기원)

Unifying coupling and connascence metrics

Architecture Characteristics Defined

software solution은 domain requiremnts와 architectural characteristics로 구성된다.

• Auditability
• Performance
• Security
• Requirements
• Data
• Legality
• Scalabil ity

Identifying Architectural Characteristics

domain concerns와 요구사항 그리고 implicit domain 지식으로부터 끌어내야 한다.

Measuring and governing Architecture Characteristics

Scope of Architecture Characteristics

Component-Based Thinking

Architecture Styles

Foundations

Layered Architecture Style

Pipeline Architecture Style

Microkernel Architecture Style

Service-based Architecture Style

Event-Driven Architecture Style

Space-Based Architecture Style

Orchestration-Driven Service-Orientaed Architecture

Microservices Architecture

Choosing the Appropriate Architecture Style

Techniques and Soft skills

Architecture Descisions

Analyzing Architecture Risk

Risk Matrix
risk에 대한 qualification

risk 발생시의 영향 (low, medium, high)와
risk가 발생활 확률 (low, medium, high)에 대한 2차원 matrix(risk assessment)로 low, medium, high를 결정

둘다 low면 -> low (1)
medium + low -> low (2)
medium + medium, low + high -> medium (3

4)
high + medium, high + high -> high (6

9)

figure 20-1

이 점수를 여러 characteristics에 대해 score를 매김
x 축: component (기능 수행) 명
y 축: characteristics
cell: risk score

이를 통해 total risk 관리 가능

1. 상대적인 위험을 관리할 수 있음
2. 객관적인 위험 수치를 관리할 수 있음

snapshot이기에 개선되고 있는지 나빠지고 있는지는 알 수 없음
각 cell에 +/-를 사용해서 개선 여부를 표시할 수 있다.
더불어 단순히 +/-가 아니라, 위/아래 표시와 함께 지표 difference 수치를 함께 기입할 수도 있다.

6점 이상의 high risk item만 관리할 수도 있다.

Risk storming

Diagramming and Presenting Architecture

Making Teams Effective

Negotiation and Leadership skills

Developinkg a Career Path