클린 아키텍처(Clean Architecture)38 클린 아키텍처:소프트웨어 구조와 설계의 원칙(Clean Architecture) - 4부 : 컴포넌트 원칙 (12장) [4부] 컴포넌트 원칙 SOLID 원칙이 벽과 방에 벽돌을 배치하는 방법을 알려준다면, 컴포넌트 원칙은 빌딩에 방을 배치하는 방법을 설명해준다. [12장] 컴포넌트 컴포넌트는 배포 단위다. 컴포넌트는 시스템의 구성 요소로 배포할 수 있는 가장 작은 단위다.(jar, dll) 컴파일형 언어에서 컴포넌트는 바이너리 파일의 결합체다. 인터프리터형 언어의 경운느 소스 파일의 결합체다. 여러 컴포넌트를 서로 링크하여 실행 가능한 단일 파일로 생성할 수 있다. 또는 컴포넌트 각각을 .jar .dll 같이 동적으로 로드할 수 있는 플러그인이나 .exe 파일로 만들어서 독립적으로 배포할 수도 있다. 잘 설계된 컴포넌트라면 반드시 독립적으로 배포 가능한, 따라서 독립적으로 개발 가능한 능력을 갖춰야 한다. 링킹 로더 :.. 2020. 3. 6. 클린 아키텍처:소프트웨어 구조와 설계의 원칙(Clean Architecture) - 3부 : 설계 원칙 (11장) [11장] DIP: 의존성 역전 원칙 의존성 역전 원칙에서 말하는 ‘유연성이 극대화된 시스템’이란 소스 코드 의존성이 추상(abstraction)에 의존하며 구체(concretion)에는 의존하지 않는 시스템이다. 정적 타입 언어에서 이 말은 use, import, include 구문은 오직 인터페이스나 추상 클래스 같은 추상적인 선언만을 참조해야 한다는 뜻이다. 구체적인 대상에는 절대로 의존해서는 안 된다. 파이썬과 같은 동적 타입 언어에서도 동일한 규칙이 적용된다. 소스 코드 의존 관계에서 구체 모듈은 참조해서는 안 된다. 하지만 이들 언어의 경우 구체 모듈이 무엇인지를 정의하기가 다소 어렵다. 호출할 함수가 구현된 모듈이라면 참조하지 않기가 특히 어렵다. 이 아이디어를 규칙으로 보기는 확실히 비현실.. 2020. 3. 5. 클린 아키텍처:소프트웨어 구조와 설계의 원칙(Clean Architecture) - 3부 : 설계 원칙 (10장) [10장] ISP: 인터페이스 분리 원칙 다수의 사용자가 OPS 클래스의 오퍼레이션을 사용한다. User1은 오직 op1을, User2는 op2만을, User3는 op3만을 사용한다고 가정해보자. 그리고 OPS가 정적 타입 언어로 작성된 클래스라고 해보자. 이 경우 User1에서는 op2와 op3를 전혀 사용하지 않음에도 User1의 소스 코드는 이 두 메서드에 의존하게 된다. 이러한 의존성으로 인해 OPS 클래스에서 op2의 소스 코드가 변경되면 User1도 다시 컴파일한 후 새로 배포해야 한다. 사실 User1과 관련된 코드는 전혀 변경되지 않았음에도 말이다. 이러한 문제는 오퍼레이션을 인터페이스 단위로 분리하여 해결할 수 있다. 정적 타입 언어는 사용자가 import, use 또는 include와 .. 2020. 3. 4. 클린 아키텍처:소프트웨어 구조와 설계의 원칙(Clean Architecture) - 3부 : 설계 원칙 (9장) [9장] LSP: 리스코프 치환 원칙(Liskov Substitution Priciple) 리스코프(Liskov)는 하위 타입(subtype) 다음과 같이 정의 했다. S타입의 객체 o1 각각에 대응하는 T타입 객체 o2가 있고, T타입을 이용해서 정의한 모든 프로그램 P에서 o2의 자리에 o1을 치환하더라도 P의 행위가 변하지 않는다면, S는 T의 하위 타입이다. 이 설계는 LSP를 준수하는데, Biling 애플리케이션 행위가 License 하위 타입 중 무엇을 사용하는지에 전혀 의존하지 않기 때문이다. 이들 하위 타입은 모두 License타입을 치환할 수 있다. LSP 위반을 막기 위한 유일한 방법은 Rectangle이 실제로는 Square인지를 검사하는 메커니즘을 User에 추가하는 것이다. 하지만.. 2020. 3. 3. 클린 아키텍처:소프트웨어 구조와 설계의 원칙(Clean Architecture) - 3부 : 설계 원칙 (8장) [8장] OCP: 개방-폐쇄 원칙 소프트웨어 개체(artifact)는 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다. 소프트웨어 아키텍처가 훌륭하다면 변경되는 코드의 양이 가능한 한 최소화될 것이다. 서로 다른 목적으로 변경되는 요소를 적절하게 분리하고(단일 책임 원칙, SRP), 이들 요소 사이의 의존성을 체계화함으로써(의존성 역전 원칙, DIP) 변경량을 최소화할 수 있다. 이처럼 책임을 분리했다면, 두 책임 중 하나에서 변경이 발생하더라도 다른 하나는 변경되지 않도록 소스 코드 의존성도 확실히 조직화해야 한다. 또한, 새로 조직화한 구조에서는 행위가 확장될 때 변경이 발생하지 않음을 보장해야 한다. 컴포넌트 관계는 단방향으로만 이루어진다. (Interactor, Database, Contr.. 2020. 3. 2. 클린 아키텍처:소프트웨어 구조와 설계의 원칙(Clean Architecture) - 3부 : 설계 원칙 (7장) [7장] SRP: 단일 책임 원칙 단일 책임 원칙. 프로그래머가 이 원칙의 이름을 듣는다면 모든 모듈이 단 하나의 일만 해야 한다는 의미로 받아 들이기 쉽다. 헷갈리지 마라. 단 하나의 일만 해야 한다는 원칙은 따로 있다. 그것은 바로 함수는 반드시 단 하나의 일만 해야 한다는 원칙이다. 이 원칙은 커다란 함수를 작은 함수들로 리팩토링하는 더 저수준에서 사용 된다. SRP : 단일 모듈은 변경의 이유가 오직 하나뿐이어야 한다. 소프트웨어 시스템은 사용자와 이해관계자를 만족시키기 위해 변경된다. SRP가 말하는 ‘변경의 이유’란 바로 이들 사용자와 이해관계자를 가리킨다. SRP : 하나의 모듈은 오직 하나의 사용자 또는 이해관계자에 대해서만 책임져야 한다. ⇒ 하나의 모듈은 오직 하나의 액터에 대해서만 책.. 2020. 3. 1. 이전 1 2 3 4 5 6 7 다음