IT 서적19 [클린아키텍처] 5부 15장. 아키텍처란 5부 15장 아키텍처란 소프트웨어 아키텍처란 무엇인가? 소프트웨어 아키텍트는 무슨일을 하는가? 소프트웨어 아키텍트는 코드와 동떨어져서는 안된다. 계속 프로그래머로 남는다. 코드에서 탈피하여 고수준의 문제에 집중해야한다는 거짓말에 절대 속아넘어가서는 안된다. 앞으로도 계속 프로그래밍 작업을 할 뿐만아니라, 나머지 팀원들이 생산성을 극대화할 수 있는 설계를 하도록 방향을 이끌어 준다. 다른 프로그래머 만큼 코드를 많이 작성하지 않을 수도 있지만, 프로그래밍 작업에는 지속적으로 참여한다. 프로그래밍 작업을 계속 하지 않으면, 발생하는 문제를 경험해보지 못하게 되고, 다른 프로그래머를 지원하는 작업을 제대로 수행할 수 없다. 소프트웨어 시스템 아키텍처란 시스템을 구축했던 사람들이 만들어낸 시스템의 형태이다. -.. 2022. 8. 21. [클린 아키텍처] 14장. 컴포넌트 결합 (4부. 컴포넌트 원칙) 14장. 컴포넌트 결합 컴포넌트 사이의 관계를 설명하는 3가지 원칙, 개발 가능성과 논리적 설계 사이의 균형을 다룬다. 컴포넌트 구조와 관련된 아키텍처를 침범하는 힘은 기술적이며, 정치적이고, 가변적이다. ADP: 의존성 비순환 원칙 “컴포넌트 의존성 그래프에 순환(cycle)이 있어서는 안 된다.” 많은 개발자가 동일한 소스파일을 수정하는 경우 (큰 프로젝트, 개발팀 규모가 클수록) 악몽이 시작된다 누군가가 마지막으로 수정한 코드 때문에 망가진 부분이 동작하도록 코드를 또 수정하고 또 수정하는 작업이 계속되어 안정적인 빌드를 하지 못한 채 몇 주가 지나갈 수 있다. 문제를 해결하기 위해 주 단위 빌드와 의존성 비순환 원칙(ADP)이 만들어졌다. 주 단위 빌드(Weekly Build) 중간 규모 프로젝트.. 2022. 8. 15. 13. 컴포넌트 응집도 REP: 재사용/릴리즈 등가 원칙(Reuse/Release Equivalence Principle) 재사용 단위는 릴리즈 단위와 같다. 새로운 버전이 언제 출시되고 무엇이 변했는지를 소프트웨어 개발자들이 알아야하기 때문에 소프트웨어 컴포넌트가 릴리즈 절차를 통해 추적, 릴리즈 번호가 부여해야한다. 또한, 적절한 릴리즈 공지와 릴리즈 문서작성도 포함되어야 개발자는 변경사항을 살펴보고 기존버전을 계속 쓸지를 결정한다. 이 원칙은 소프트웨어 설계와 아키텍처 관점에서 보면 단일 컴포넌트는 응집성 높은 클래스와 모듈들로 구성되어야 함을 뜻한다. 이 원칙을 어기면 이치에 맞지 않게 된다. CCP: 공통 폐쇄 원칙(Common Closure Principle) 동일한 이유로 동일한 시점에 변경되는 클래스를 같은 컴포.. 2022. 5. 8. 4부 12장. 컴포넌트 (링킹로더, 링커, 컴포넌트) 4부 컴포넌트 원칙 컴포넌트 원칙은 빌딩에 방을 배치하는 방법을 설명한다. 대규모 소프트웨어 시스템은 작은 컴포넌트들로 만들어진다. 소프트웨어 컴포넌트가 무엇인지, 컴포넌트를 구성하는 요소는 무엇인지 알아보고, 컴포넌트를 결합하여 시스템을 구성하는 방법에 대해 논의한다. 12장. 컴포넌트 컴포넌트? 배포 단위 시스템 구성 요소로 배포할 수 있는 가장 단위 단위. 자바의 경우 jar파일 루비에서는 gem파일 닷넷에서는 DLL파일 컴파일러형 언어에서는 바이너리 파일의 결합체다. 인터프리터형 언어에서는 소스파일의 결합체다. 여러 컴포넌트를 서로 링크하여 실행 가능한 단일 파일로 생성할 수 있다. 잘 설계된 컴포넌트라면 반드시 독립적으로 배포 가능한, 따라서 독립적으로 개발 가능한 능력을 갖춰야 한다. 컴포넌트.. 2022. 4. 10. 11장. DIP: 의존성 역전 원칙(Dependency Inversion Principle) 11장. DIP: 의존성 역전 원칙(Dependency Inversion Principle) 고수준 정책을 구현하는 코드는 저수준 세부사항을 구현하는 코드에 절대로 의존해서는 안된다. 대신 세부사항이 정책에 의존해야 한다. 의존성 역전 원칙에서 말하는 ‘유연성이 극대화된 시스템’이란 소스 코드 의존성이 추상(abstraction)에 의존하며 구체(concretion)에는 의존하지 않는 시스템이다. DIP를 논할 때 운영체제나 플랫폼 같이 안정성이 보장된 환경에 대해서는 무시하는 편이다. 환경에 대한 의존성은 용납한다. 변경되지 않는다면 의존할 수 있다는 사실을 이미 알고 있기 때문이다. 의존하지 않고 피하고자 하는 것은 바로 변동성이 큰 구체적인 요소이다. 이 요소는 우리가 열심히 개발하는 중이라 자주 .. 2022. 3. 21. 10장. ISP: 인터페이스 분리 원칙(interface Segregation Principle) 10장. ISP: 인터페이스 분리 원칙(interface Segregation Principle) 소프트웨어 설계자는 사용하지 않은 것에 의존하지 않아야 한다. 위 그림의 상황에서 User1은 op1만을, User2는 op2만을, User3은 op3만을 사용한다고 가정해보자. 또, OPS가 정적타입언어로 작성된 클래스라고 가정해보자. 이 경우 User1은 op2, op3을 사용하지 않음에도 소스코드는 의존하게된다. (만약, op2코드가 변경되면 User1과 관련된 코드는 전혀 변경되지 않았더라도 재컴파일후 배포해야한다.) 아래처럼 오퍼레이션을 인터페이스 단위로 분리하여 해결할 수 있다. ISP와 언어 정적 타입언어 (java) : 사용자가 import, use, include 같은 타임 선언문을 반드시 .. 2022. 3. 21. 9장. LSP: 리스코프 치환 원칙(Liskov Substitution Principle) 9장. LSP: 리스코프 치환 원칙(Liskov Substitution Principle) 1988년 바바라 리스코프가 정의한 하위타입에 관한 원칙. 상호 대체 가능한 구성요소를 이용해 소프트웨어 시스템을 만들 수 있으려면, 이들 구성요소는 반드시 서로 치환 가능해야 한다는 계약을 반드시 지켜야 한다. 상속을 사용하도록 가이드하기 위 설계는 LSP를 준수한다. Billing 애플리케이션의 행위가 License 하위 타입 중 무엇을 사용하는지에 전혀 의존하지 않기 때문이다. 하위 타입은 모두 License로 치환할 수 있다. 정사각형/직사각형 문제 Square는 Reactangle의 하위 타입으로 적합하지 않다. User는 대화하고 있는 상대가 Rectangle이라고 생각하므로 혼동이 생길 수 있다. 이 .. 2022. 3. 21. SOLID 설계원칙 - 8장. OCP: 개방-폐쇄 원칙(Open-Closed Principle) 8장. OCP: 개방-폐쇄 원칙(Open-Closed Principle) 1980년대 버트란트 마이어에 의해 유명해진 원칙. 기존 코드를 수정하기보다는 반드시 새로운 코드를 추가하는 방식으로 시스템의 행위를 변경할 수 있도록 설계해야만 소프트웨어 시스템을 쉽게 변경할 수 있다는 것. 소프트웨어 개체의 행위는 확장할 수 있어야 하지만, 이때 개체를 변경해서는 안된다. OCP는 클래스와 모듈을 설계할 때 도움 되는 원칙으로 알고 있지만 아키텍처 컴포넌트 수준에서 중요한 의미를 가진다. 사고 실험 제무제표를 웹페이지를 보여주는 시스템이 존재한다고 가정하자. 프린터로 출력하는 기능을 추가하도록 요청했다고 하자. 이때, 소프트웨어 아키텍처가 훌륭하다면 변경되는 코드 양이 가능한 한 최소화될 것이다. 단일 책임 원.. 2022. 3. 4. SOLID 설계원칙 7장. SRP:단일 책임 원칙(Single Responsibility Principle) SOLID의 목적은 중간 수준의 소프트웨어 구조가 아래와 같도록 만드는데 목적이 있다. 변경에 유연하다. 이해하기 쉽다. 많은 소프트웨어 시스템에 사용될 수 있는 컴포넌트의 기반이 된다. 7장. SRP: 단일 책임 원칙 (Single Responsibility Principle) 콘웨이 법칙에 따른 따름 정리: 소프트웨어 시스템이 가질 수 있는 최적의 구조는 시스템을 만드는 조직의 사회적 구조의 커다란 영향을 받는다. 따라서 각 소프트웨어 모듈은 변경의 이유가 하나, 단 하나여야만 한다. (하나의 모듈은 하나의, 오직 하나의 액터에 대해서만 책임져야 한다.) 단 한 가지 일만 해야 한다는 원칙이 아니다. 오해하지 말기. 위반하는 징후들을 살펴보자. 징후 1: 우발적 중복 Employee 클래스는 세 가지.. 2022. 3. 4. [클린 아키텍처] 2부. 벽돌부터 시작하기: 프로그래밍 패러다임 (구조적/객체지향/ 함수형 프로그래밍) 2부 벽돌부터 시작하기: 프로그래밍 패러다임 3장. 패러다임 개요 구조적 프로그래밍 최초로 적용된 패러다임 하지만 최초로 만들어진 패러다임은 아니다. 1968년 에츠허르 비버 데이크스트라가 발견했다. 구조적 프로그래밍은 제어 흐름의 직접적인 전환에 대해 규칙을 부과한다 객체 지향 프로그래밍 두 번째로 도입된 패러다임 구조적 프로그래밍 보다 2년 앞선 1966년에 올레 요한 달과 크리스텐 니가드에 의해 등장했다. 알골(ALGOL)언어의 함수 호출 스택 프래임을 힙으로 옮기면 함수 호출이 반환된 이후에도 함수에서 선언된 지역변수가 오랫동안 유지될 수 있음을 발견했다. 객체 지향 프로그래밍은 제어흐름의 간접적인 전환에 대해 규칙을 부과한다. 함수형 프로그래밍 최근에 들어서야 도입되기 시작했다. 만들어진 것은 .. 2022. 2. 27. 이전 1 2 다음
