책/클린 아키텍쳐 (완) (6) 썸네일형 리스트형 6부 세부사항 30 데이터베이스는 세부사항이다.아키텍처 관점에서 볼 떄 데이터베이스는 엔티티가 아니다. 즉, 데이터베이스는 세부사항이라서 아키텍처의 구성요소 수준으로 끌어올릴 수 없다. 관계형 데이터베이스많은 데이터 접근 프레임워크가 테이블과 행이 객체 형태로 시스템 여기저기에서 돌아다니게 허용하는데, 아키텍처적으로 잘못된 설계다.디스크가 없다면 어떻게 될까?데이터를 파일이나 테이블 형태로 그대로 두는 경우는 거의 없다.하지만 성능은?성능은 시스템의 전반적인 아키텍처와는 아무런 관련이 없다.32장 프레임 워크은 세부사항이다.프레임워크 제작자물론 당신의 문제는 프레임워크가 풀려는 문제와 꽤 많이 겹칠 것이다.겹치는 영역이 크면 클수록 프레임워크는 실제로 더 유용해진다.해결책프레임워크를 사용할 수는 있다. 다만 프레임워크.. 5부 아키텍처 15장 아키텍처란?소프트웨어 아키텍트라면 코드에서 탈피하여 고수준의 문제에 집중해야 한다는 거짓말에 절대로 속아 넘어가서는 안 된다.소프트웨어 시스템의 아키텍처란 시스템을 구축했던 사람들이 만들어낸 시스템의 형태다. 그 모양은 시스템을 컴포넌트로 분할하는 방법, 분할된 컴포넌트를 배치하는 방법, 컴포넌트가 서로 의사소통하는 방식에 따라 정해진다.아키텍처의 주된 목적은 시스템의 생명주기를 지원하는 것이다.아키텍처의 궁극적인 목표는 시스템의 수명과 관련된 비용은 최소화하고, 프로그래머의 생산성은 최대화하는 데 있다.개발시스템 아키텍처는 개발팀이 시스템을 쉽게 개발할 수 있도록 뒷받침해야만 한다.팀별 단일 컴포넌트 아키텍처가 시스템을 배포, 운영, 유지보수하는데 최적일 가능성은 거의 없다.배포소프트웨어 시스템.. 4부 컴포넌트 원칙 12장 컴포넌트컴포넌트는 시스템의 구성 요소로 배포할 수 있는 가장 작은 단위다. 13장 컴포넌트 응집도이 장에서는 컴포넌트 응집도와 관련된 세 가지 원칙을 논의한다.REP: 재사용/릴리스 등가 원칙CCP: 공통 폐쇄 원칙CRP: 공통 재사용 원칙REP: 재사용/릴리스 등가 원칙이 원칙을 소프트웨어 설꼐와 아키텍처 관점에서 보면 단일 컴포넌트는 응집성 높은 클래스와 모듈들로 구성되어야 함을 뜻하다. CCP: 공통 폐쇄 원칙동일한 이유로 동일한 시점에 변경되는 클래스르 같은 컴포넌트로 묶어라. 서로 다른 시점에 다른 이유로 변경되는 클래스는 다른 컴포넌트로 분리하라.이 원칙은 단일 책임 원칙을 컴포넌트 관점에서 다시 쓴 것이다.단일 컴포넌트는 변경의 이유가 여러 개 있어서는 안 된다고 말한다.SRP와의 유.. 3부 설계원칙 들어가며코드 수준부다는 조금 상위에서 적용되며 모듈과 컴포넌트 내부에서 사용되는 소프트웨어 구조를 정의하는 데 도움을 준다.3부에서는 각 원칙을 더 면밀하게 살펴본다. 아래는 이들 원칙의 개략적인 설명이다.SRP: 단일 책임 원칙OCP: 개방-폐쇄 원칙LSP: 리스코프 치환 원칙ISP: 인터페이스 분리 원칙DIP: 의존성 역전 원칙 7장 SRP: 단일 책임 원칙이제 SRP의 최종 버전은 아래와 같다. "하나의 모듈은 하나의, 오직 하나의 액터에 대해서만 책임져야 한다."'응집된'이라는 단어가 SRP를 암시한다. 단일 액터를 책임지는 코드를 함께 묶어주는 힘이 바로 응집성이다.징후1: 우발적 중복이러한 문제는 서로 다른 액터가 의존하는 코드를 너무 가까이 배치했기 때문에 발생한다. SRP는 서로 다른 액터.. 2부 벽돌부터 시작하기: 프로그래밍 패러다임 3장 패러다임 개요 구조적 프로그래밍 구조적 프로그래밍은 제어흐름의 직접적인 전환에 대해 규칙을 부과한다. 객체 지향 프로그래밍 객체 지향 프로그래밍느 제어흐름의 간접적인 전환에 대해 규칙을 부과한다. 함수형 프로그래밍 함수형 프로그래밍은 할당문에 대해 규칙을 부과한다. 5장 객체 지향 프로그래밍 좋은 아키텍처를 만드는 일은 객체 지향 oo 설계 원칙을 이해하고 응용하는데서 출발한다. oo의 본질을 설명하기 위해 세 가지 주문에 기대는 부류도 있는데, 캡슐화, 상속, 다형성이 바로 그 주문이다. 캡슐화? 이 때문(기존의 C언어에서도 완벽한 캡슐화가 가능했다.)에 OO가 강력한 캡슐화에 의존한다는 정의는 받아들이기 힘들다. 실제로 많은 OO언어가 캡슐화를 거의 강제하지 않는다. 상속? 따라서 OO 언어가 .. 1부 소개 1장 설계와 아키텍쳐란? 우선 첫째로 주장하고 싶은 바는 둘(설계, 아키텍쳐) 사이에는 차이가 없다는 점이다. 개별로는 존재할 수 없고, 실제로 이 둘을 구분 짓는 경계는 뚜렷하지 않다. 무엇이 잘못되었나? 이들 개발자는 "코드는 나중에 정리하면 돼. 당장은 시장에 출시하는게 먼저야!" 라는 흔해 빠진 거짓말에 속는다. 엉망으로 만들면 깔끔하게 유지할 때보다 항상 더 느리다. 시간 척도를 어떻게 보든지 관계없이 말이다. 빨리 가는 유일한 방법은 제대로 가는 것이다. 2장 두가지 가치에 대한 이야기 행위 이들은(프로그래머) 요구사항을 기계에 구현하고 버그를 수정하는 일이 자신의 직업이라고 믿는다. 슬픈 일이지만 그들은 틀렸다. 아키텍쳐 소프트웨어가 가진 본연의 목적을 추구하려면 소프트웨어는 반드시 '부드러.. 이전 1 다음
