SOLID 원칙의 목적은 중간 수준의 소프트웨어 구조가 아래와 같도록 만드는 데 있다. 변경에 유연하다. 이해하기 쉽다. 많은 소프트웨어 시스템에 사용될 수 있는 컴포넌트의 기반이 된다. SOLID 원칙 SRP(단일 책임 원칙): 하나의 모듈은 하나의, 오직 하나의 액터에 대해서만 책임져야 한다. OCP(개방-폐쇄 원칙): 기존 코드를 수정하기보다는 반드시 새로운 코드를 추가하는 방식으로 시스템의 행위를 변경할 수 있도록 설계해야만 소프트웨어 시스템을 쉽게 변경할 수 있다. LSP(리스코프 치환 원칙): 상호 대체 가능한 구성요소를 이용해 소프트웨어 시스템을 만들 수 있으려면, 상위 타입 자리에 하위 타입으로 치환할 수 있어야된다....
소프트웨어 아키텍처는 코드로부터 시작한다. 프로그래밍 언어는 쉴 틈 없이 쏟아져나왔으며, 프로그래밍 패러다임도 몰아쳤다. 패러다임: 프로그래밍을 하는 방법으로 대체로 언어에 독립적이다. 패러다임은 어떤 프로그래밍 구조를 사용할지, 그리고 언제 이 구조를 사용해야 하는지를 결정한다. 패러다임 개요 구조적 프로그래밍: 제어흐름의 직접적인 전환에 대해 규칙을 부과한다. 무분별한 점프는 프로그램 구조에 해롭다는 사실을 제시했다. 객체 지향 프로그래밍: 제어흐름의 간접적인 전황에 대해 규칙을 부과한다. 함수 호출 스택 프레임을 힙으로 옮기면, 함수 호출이 반환된 이후에도 함수에서 선언된 지역변수가 오랫동안 유지될 수 있음을 발견했다....
소프트웨어를 올바르게 만드는 일은 어렵다. 소프트웨어를 제대로 만들려면 적정 수준의 지식과 기술이 겸비해야 한다. 소트웨어를 제대로 만들면 아주 적은 인력만으로도 새로운 기능을 추가하거나 유지보수할 수 있다. 변경은 단순해지고 빠르게 반영할 수 있따. 결함은 적어지고 잦아든다. 설계와 아키텍처란 설계와 아키텍처 사이에는 차이가 없다. 아키텍처는 고수준의 무언가를 가리킬 떄 흔히 사용되는 반면, 설계는 저수준의 구조 또는 결정사항 등을 의미할 떄가 많다. 저수준의 세부사항과 고수준의 구조는 모두 소프트웨어 전체 설계의 구성요소다. 이 둘을 구분 짓는 뚜렷한 경계는 없다....
데이터베이스는 세부사항이다 애플리케이션 내부 데이터의 구조는 시스템 아키텍처에서 대단히 중요하다. 하지만 데이터베이스는 데이터 보델이 아닌 소프트웨어일 뿐이다. 아키텍처 관점에서 이러한 유틸리티닌 저수준의 세부사항일 뿐이라서 아키텍처와는 관련이 없다. 데이터베이스 시스템이 우위를 차지할 수 있었던 이유는 디스크 떄문이다. 느린 디스크를 개선하기 위해 색인, 캐시, 쿼리 계획 최적화가 필요했다. 이를 위해ㅅ 데이터 접근 및 관리 시스템이 필요했다. 파일 시스템: 문서 기반. 문서의 이름을 기준으로 조회할 떄는 잘 동작하지만, 내용을 기준으로 검색할 떄는 크게 도움되지 않는다....
아키텍처란? 아키텍처의 주목적: 시스템의 생명주기 지원 시스템을 쉽게 이해하고, 쉽게 개발하며, 쉽게 유지보수하고, 쉽게 배포하게 해준다. 팀 구조에 따라 아키텍처가 결정이 날 수도 있다. 작은 규모의 팀이라면 모노리틱 시스템으로 개발할 수도 있다. 팀 규모가 클 때, 안정된 인터페이스가 없고 잘 설계된 컴포넌트로 분리되어 있지 않다면 각 팀마다 하나씩 컴포넌트를 가질 가능성이 높다. 소프트웨어 아키텍처는 시스템을 단 한 번에 쉽게 배포할 수 있도록 만드는 데 목표를 두어야 한다. 개발 초기 단계에 MSA를 사용하자고 결정할 경우, 컴퓨넌트 경계가 뚜렷해지고 인터페이스가 안정화되므로 시스템을 매우 쉽게 개발할 수 있다고 판단할 수 도 있다....
컴포넌트 컴포넌트: 시스템의 구성 요소로 배포할 수 있는 가장 작은 단위. 자바의 jar, 루비의 gem, 닷넷의 DLL… 여러 컴포넌트를 서로 링크하여 실행 가능한 단일 파일로 생성할 수 있다. 또는, 여러 컴포넌트를 서로 묶어서 .war 파일과 같은 단일 아카이브로 만들 수도 있따. 또는 컴포넌트 각각을 .jar나 .dll같이 독적으로 로드할 수 있는 플러그인이나 .exe 파일로 만들어서 독립적으로 배포할 수도 있다. 컴포넌트의 간략한 역사 소프트웨어 개발 초창기에는 메모리에서의 프로그램 위치와 레이아웃을 프로그래머가 직접 제어했다....