본문 바로가기

전체 글

 (128)
05 아키텍처 - 4 22장 클린 아키텍처 관심사 분리- 소프트웨어를 계층으로 분리. - 최소한 업무규칙을 위한 계층, 사용자와 시스템 인터페이스를 위한 다른계층 하나 포함. 프레임워크 독립성 테스트 용이성. UI 독립성 데이터베이스 독립성. 모든 외부 에이전시 에 대한 독립성 의존성 규칙 보통 안으로 들어갈수록 고수준의 소프트웨어. 바깥쪽 - 메커니즘, 안쪽 -정책 소스코드 의존성은 반드시 안쪽으로, 고수준의 정책을 향해야 한다. 외부원에 위치한 것은 내부 원에 영향을 주지 않게 해야한다. 엔티티 엔티티는 핵심업무 고수준인 규칙을 캡슐화 함. 해당 애플리케이션의 업무 객체. 유스케이스 유스케이스 계층은 애플리케이션 특화 업무규칙을 포함. 엔티티로 들어오고 나가는 데이터 흐름을 조정. 이 계층에서 발생한 변경이 엔티티에 영향..
05 아키텍처 - 3 19장 정책과 수준 소프트 웨어 시스템 - 정책을 기술한 것. 아키텍처 개발은 재편성된 컴포넌트들을 비순환 방향 그래프로 구성하는 기술을 포함. 의존성은 소스코드, 컴파일타임의 의존성. 자바의 경우 import, C#에서는 using 구문, 루비에서는 require 구문. 각 컴포넌트를 연결할 때 의존성의 방향이 컴포넌트의 수준을 기반으로 연결되도록 만들어야 함. 저수준 컴포넌트가 고주순 컴포넌트에 의존하도록 설계 수준 level : 입력과 출력까지의 거리 입력과 출력을 다루는 정책이라면 시스템 최하위 수준에 위치하게 함. 소스코드 의존성은 그 수준에 따라 결합되어야 하며, 데이터 흐름을 기준으로 결합되서서는 안됨. function encrypt() { while(true) writeChar(transl..
05 아키텍처 - 2 16장 독립성 좋은 아키텍처가 시스템에서 지원해야 할 것. 유스케이스 운여 개발 배포 유스케이스 시스템의 아키텍처는 시스템의 의도를 지원해야 한다. 행위를 명확히 하고 외부로 드러내서 이를통해 시스템이 지닌 의도를 아키텍처 수준에서 알아볼 수 있게 만드는 것. 운영 운영지원 관점에서 아키텍처는 요구사항에 맞게 운영작업을 허용할 수 있는 형태로 구조화되야 한다. 아키텍처에서 각 컴포넌트를 적절히 격리하여 유지하고 컴포넌트 간 통신 방식을 특정 형태로 제한하지 않으면, 나중에 운영에 필요한 요구사항이 바뀌더라도 기술 스펙트럼 사이를 전화하는 일이 훨씬 쉽다. 개발 개발환경을 지원하는데 있어 아키텍처는 핵심적인 역할을 한다. Conway 법칙 시스템을 설계하는 조직이라면 어디든지 그 조직의 의사소통 구조와 동..
05 아키텍처 - 1 15장 아키텍처란? 소프트웨어 아키텍트는 코드와 동떨어져서는 안되며, 팀원들이 생산성을 극대화할 수 있는 설계를 하도록 방향을 이끌어야 한다. 시스템을 구축했던 사람들이 만들어낸 시스템의 형태. 그 형태는 아키텍처 안에 담긴 소프트웨어 시스템이 쉽게 개발, 배포, 운영, 유지보수 되도록 만든다. 주된 목적은 시스템의 생명주기를 지원하는 것이다. 궁극적 목표는 시스템의 수명과 관련되 비용은 최소화하고, 프로그래머의 생산성은 최대화 하는데 있다. 개발 개발팀이 시스템을 쉽게 개발하도록 뒷받침. 작은 규모의 개발팀이라면 이러한 아키텍처 제약사항들이 방해가 된다고 느낄수도 있으나, 여러팀이 개발하고있다면 신뢰할 수 있는 안정된 인터페이스를 갖춘, 설계된 컴포넌트 단위로 분리하지 않으면 개발이 진척되지 않는다. ..
04 컴포넌트 원칙 -2 컴포넌틑 응집도와 관련된 세가지 원칙 REP: The Reuse/Release Equivalence Principle CCP: The Common Closure Principle CRP: The Common Reuse Principle 13장 컴포넌트 응집도 Component Cohesion REP: 재사용/릴리스 등가 원칙 재사용 단위는 릴리스 단위와 같다. 릴리즈 번호가 없으면 재사용 컴포넌트들이 서로 호환되는지 보증할 수 없음. 하나의 컴포넌트로 묶인 클래스와 모듈은 반드시 함께 릴리스 가능해야 함. CCP: 공통 폐쇄 원칙 동일한 이유로 동일한 시점에 변경되는 클래스를 같은 컴포넌트에 묶어라. 서로 다른 시점에 다른 이유로 변경되는 클래스는 다른 컴포넌트에 분리 단일 컴포넌트는 변경의 이유가 여러..
04 컴포넌트 원칙 -1 SOLID 원칙이 벽과 방에 벽돌을 배치하는 방법이라면, 컴포넌트 원칙은 빌딩에 방을 배치하는 방법이다. 12장 컴포넌트 모든 언어에서 컴포넌트는 배포할 수 있는 단위 입자다. 자바의 경우 jar 파일, 루비는 gem 파일, 닷넷은 DLL, 컴파일형 언어는 바이너리 파일의 결합체, 인터프리터형은 소스파일의 결합체, 여러 컴포넌트를 서로 링크해 실행가능한 단일파일로 생성 가능하고, 여러 컴포넌트를 서로 묶어 .war 파일처럼 단일 아카이브로 생성도 가능. 컴포너트 각각을 독립적으로도 배포 가능. 컴포넌트의 역사 프로그래밍 초창기에는 프로그램을 메모리의 어느 위치에 로드할지 프로그래머가 직접 결정해야 했다. 라이브러리 함수 소스코드를 애플리케이션 코드에 직접 포함시켜 단일 프로그램으로 컴파일 했다. 프로그램..
03 설계원칙 -2 10장 ISP: 인터페이스 분리 원칙 The Inteface Segregation Principle 다수의 사용자가 OPS 클래스의 오퍼레이션을 사용. 이런 의존성으로 OPS 클래스에서 op2 소스코드가 변경되면 User1도 다시 컴파일한 후 배포해야함. 오퍼레이션을 인터페이스 단위로 분리하여 해결. ISP와 언어 정적타입 언어의 경우 include 선언문으로 소스코드 의존성이 발생함. 동적타입 언어는 선언문이 존재하지 않고 런타임에 추론이 발생. 따라서 소스코드 의존성이 존재하지 않아 유연하고 결합도가 낮은 시스템을 만들 수 있음. ISP와 아키텍처 필요이상으로 많은걸 포함하는 모듈에 의존하는 것은 해로움. 불필요한 재컴파일과 재배포를 강제하기 때문. 결론 불필요한 짐을 실은 무언가에 의존하면 예상못한..
03 설계원칙 - 1 7장 SRP: 단일 책임 원칙 함수는 반드시 하나의 일만 해야한다는 원칙. 하나의 모듈은 하나의 오직한의 액터에 대해서만 책임져야 한다. 단일 액터를 책임지는 코드를 함께 묶어주는 힘이 응집성 cohesion. 징후 1: 우발적 중복 단일클래스에 세 메서드가 배치되어 세 액터가 서로 결함됨. 변경이 일어날 경우 그것에 의존하는 무언가여 영향을 주게됨. 서로 다른 액터가 의존하는 코드를 너무 가까이 배치해서 발생하는 문제. SRP는 서로 다른 액터가 의존하는 코드를 서로 분리하라고 한다. 징후 2: 병합 병합은 항상 위험이 뒤따른다. 문제를 벗어나는 방법은 서로 다른 액터를 뒷받침하는 코드를 서로 분리하는 것. 해결책 메서드를 각기 다른 클래스로 이동시키는 방식. 아무런 메서드가 없는 간단한 데이터 구조인..

티스토리툴바