• 지난 반세기동안 하드웨어는 더 작아지고 빨라졌지만, 소프트웨어를 구성하는 것들은 조금도 바뀌지 않았다. 그렇기에 좋은 소프트웨어 아키텍처를 만드는 원칙은 보편적이며 시간이 지나더라도 변함이 없다.
• 아키텍처의 매력은 그 구조에 있다. 구조란 패러다임을 지배하고 소프트웨어 개발의 논의를 지배하는 무언가로서, 컴포넌트, 클래스, 함수, 모듈, 계층, 서비스(마이크로서비스든 아니든)가 그 예이다.
• 소프트웨어 아키텍처에서 물리학이나 물리적인 규모를 말하는 것은 의미가 없지만, 반드시 신경 써야 할 물리적인 제약은 존재한다. ( 프로세서 속도와 네트워크 대역폭, 메모리, 스토리지와 같은 것들 )
• 좋은 아키텍처는 사용자, 개발자, 소유자의 요구를 특정 시점에도 반드시 충족시켜줄 뿐만 아니라, 시간이 흐르더라도 계속 충족시켜 준다.

1장 설계와 아키텍처란?

• 설계(design)와 아키텍처(architecture)는 오랫동안 많은 혼란이 있었지만 사실 아무런 차이가 없다.
• 저수준의 세부사항과 고수준의 구조는 모두 소프트웨어 전체 설계의 구성요소이다.
• 고수준에서 저수준으로 향하는 의사결정의 연속성만이 있을 뿐이다.
• 소프트웨어 아키텍처의 목표는 필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화하는 데 있다.
• 개발조직이 할 수 있는 최고의 선택지는 조직에 스며든 과신을 인지하여 방지하고, 소프트웨어 아키텍처의 품질을 심각하게 고민하기 시작하는 것이다.

2장 두 가지 가치에 대한 이야기

• 소프트웨어라는 단어에서도 알 수 있듯이 소프트웨’어는 부드러움을 지니도록’ 만들어졌다.
  • 따라서 반드시 ‘부드러워’야 한다. 이는 다시 말해 변경하기 쉬워야 한다는 뜻이다.
• 변경사항을 적용하는 데 드는 어려움은 변경되는 범위(scope)에 비례해야 하며, 변경사항의 형태(shape)와는 관련이 없어야 한다.
• 아키텍처는 형태에 독립적이어야 하고, 그럴수록 더 실용적이다.
• 소프트웨어 개발자도 소프트웨어 아키텍처를 안전하게 보호(?)해야 할 책임이 있으므로, 비지니스와 소프트웨어 관점 모두 적절한 밸런스를 가지고 운영이 될 수 있도록 노력해야한다.