💡 아키텍처란

<aside> 💡 소프트웨어 아키텍처란, 시스템을 구축했던 사람들이 만들었던 형태

</aside>

• 시스템을 컴포넌트로 분할하는 방법, 분할된 컴포넌트를 배치하는 방법, 컴포넌트가 서로 의사소통 하는 방식에 따라 정해짐
• 시스템의 동작 여부와는 거의 관련이 없음
• 좋은 아키텍처를 구축하면, 시스템을 쉽게 이해 / 개발 / 유지보수 / 배포 할 수 있음
• 개발의 관점에서 본 아키텍처
  • 인원이 소수라면, 컴포넌트 / 인터페이스가 없더라도 개발이 잘 될 수 있음
  • 하지만 인원이 많아진다면, 컴포넌트 분리 / 정의된 인터페이스 없이는 개발이 불가능
• 배포의 관점에서 본 아키텍처
  • 배포 비용이 높을 수록 시스템의 유용성은 떨어짐
  • 시스템을 단 한번에 쉽게 배포 할 수 있도록 노력 해야 함
  • microservice architecture는 개발 초기에 컴포넌트 경계가 뚜렷해지고 인터페이스를 정하기 쉬운 장점이 있으나, 배포에 있어선 문제가 많을 수 있음
• 운영의 관점에서 본 아키텍처
  • 하드웨어를 더 쓰면 해결될 문제는 개발자를 더 투입하여야 하는 문제보다 더 저렴한 경우가 많다
  • 즉 운영의 관점에서는, 운영을 방해하는 아키텍처가 개발 / 배포 / 유지보수를 방해하는 아키텍처보다 비용이 덜 든다는 것
• 유지보수의 관점에서 본 아키텍처
  • 유지보수는 소프트웨어 시스템에서 비용이 가장 많이 드는 작업
  • 유지보수에서 가장 비용이 많이 드는 곳은 기능 추가 / 수정 시에 어떻게 작업 하는것이 최적인지를 결정하는 탐사 작업
  • 아키텍처는 이러한 탐사 작업에 드는 비용을 최소화 할 수 있음
• 선택사항 열어두기 관점에서 본 아키텍처
  • 소프트웨어는 기계의 행위를 빠르고 쉽게 변경 할 수 있어야 함
  • 이러한 유연성은 시스템의 형태, 컴포넌트의 배치 방식, 연결 방식에 상당히 크게 의존
  • 소프트웨어를 유연하게 하기 위해선, 선택 사항 ( 세부 사항 )들을 가능한 많이, 그리고 가능한 오랫동안 열어 두어야 함
  • 정책 / 세부사항에 대해
    • 정책 → 시스템이 이루고자 하는 가치
    • 세부사항 → 웹서버 / 프레임워크 / 통신 프로토콜 등 프로그래머가 정책과 소통 할 때 가장 많이 사용되는 요소
    • 정책을 가장 중요하게, 세부 사항을 정책과 무관하게 만드는 시스템이 가장 이상적인 시스템
    • 고수준의 정책은, 어떤 종류의 데이터베이스 / 웹서버 등을 사용하는지 신경 써서는 안되며, 독립 적이어야 함
  • 세부사항을 무시한 채 정책을 만들어 놓아야, 나중에 분리 가능한 아키텍처를 설계 할 수 있음
  • 결정 되지 않은 사항의 수를 최대화 하는 것이 좋은 아키텍처의 목표

<aside> 💡 좋은 아키텍처란, 세부 사항으로 부터 정책을 신중하게 가려내고, 정책이 세부사항과 결합되지 않도록 업격하게 구분 해야 함

</aside>

<aside> 💡 정책은 세부사항에 대한 어떠한 지식도 갖지 못해야 하며, 어떤 경우에도 세부사항에 의존해서는 안됨

</aside>