클린아키텍쳐 - 소프트웨어의 구조와 설계의 원칙[7부 34장]

클린아키텍쳐 - 소프트웨어의 구조와 설계의 원칙[7부 34장]

 

1부 소개

1장: 디자인과 건축이란 무엇인가? 이 장에서는 소프트웨어 개발의 설계 및 아키텍처에 대한 개요를 제공합니다. 저자는 좋은 소프트웨어 디자인이 시간이 지남에 따라 변화하는 요구 사항에 적응할 수 있는 유지 관리 가능하고 확장 가능하며 유연한 응용 프로그램을 만드는 데 중요하다고 설명합니다. 그는 또한 소프트웨어 개발에서 아키텍처의 역할과 프레임워크, 라이브러리 및 아키텍처 패턴의 선택과 같은 애플리케이션의 상위 구조에 대한 결정을 내리는 방법에 대해 설명합니다.

2장: 두 가지 가치에 대한 이야기 이 장에서는 소프트웨어 개발의 두 가지 가치인 단순성과 유연성 사이의 긴장을 탐구합니다. 저자는 이 두 가지 가치가 서로 충돌하는 경우가 많으며 올바른 균형을 찾는 것이 좋은 소프트웨어 디자인을 만드는 데 핵심이라고 주장합니다. 그는 설계 결정을 내릴 때 단순성과 유연성 간의 절충점을 고려하는 것의 중요성을 강조하고 유지 관리 가능성, 확장성 및 적응성 측면에서 다양한 접근 방식이 어떻게 다른 결과를 가져올 수 있는지에 대한 예를 제공합니다.

2부 벽돌부터 시작하기: 프로그래밍 패러다임

3장: 패러다임 개요 프로그래밍 세계에서 프로그래밍 패러다임은 개발자가 코드를 작성하는 방법을 안내하는 기본적인 접근 방식 또는 프로그래밍 스타일입니다. 고유한 기능과 이점이 있는 몇 가지 프로그래밍 패러다임이 있으며 이러한 패러다임을 이해하는 것은 자신의 기술을 향상시키려는 프로그래머에게 필수적입니다.

4장: 구조화된 프로그래밍 구조적 프로그래밍은 코드의 명확성, 가독성 및 유지 관리성을 향상시키기 위해 루프, 조건문 및 서브루틴과 같은 구조적 제어 흐름 구조의 사용을 강조하는 프로그래밍 패러다임입니다. 저수준 기계 언어로 작업할 때 인식되는 복잡성과 어려움에 대한 응답으로 개발되었습니다.

5장: 객체 지향 프로그래밍 OOP(객체 지향 프로그래밍)는 데이터와 동작을 캡슐화하는 클래스의 인스턴스인 객체 개념을 기반으로 하는 프로그래밍 패러다임입니다. OOP는 상속, 다형성 및 캡슐화와 같은 개념을 강조하여 보다 모듈화되고 재사용 가능하며 유연한 코드를 허용합니다.

6장: 함수형 프로그래밍 함수형 프로그래밍은 함수를 소프트웨어의 기본 빌딩 블록으로 사용하는 것을 강조하는 프로그래밍 패러다임입니다. 변경할 수 없는 데이터를 강조하고 부작용을 방지하여 코드를 더 쉽게 추론하고 테스트할 수 있습니다. 기능적 프로그래밍 언어는 종종 더 간결하고 표현적인 코드를 허용하는 고차 함수, 재귀 및 클로저를 지원합니다.

3부 설계원칙

7장: SRP - 단일 책임 원칙 SRP(Single Responsibility Principle)는 객체 지향 프로그래밍의 원칙으로, 클래스나 모듈은 변경해야 할 이유가 하나만 있어야 합니다. 즉, 클래스는 하나의 책임만 가져야 이해, 유지 및 수정이 더 쉬워집니다.

8장: OCP - 개방-폐쇄 원칙 OCP(Open-Closed Principle)는 소프트웨어 엔터티(클래스, 모듈, 함수 등)가 확장에는 열려 있어야 하지만 수정에는 닫혀 있어야 한다는 객체 지향 프로그래밍의 원칙입니다. 즉, 기존 코드를 수정하지 않고도 시스템의 동작을 확장할 수 있어야 합니다.

9장: LSP - Liskov 대체 원리 LSP(Liskov Substitution Principle)는 프로그램의 정확성에 영향을 미치지 않고 상위 클래스의 개체를 하위 클래스의 개체로 대체할 수 있어야 한다는 개체 지향 프로그래밍의 원칙입니다. 이 원칙은 하위 클래스가 일관되고 예측 가능한 방식으로 동작하도록 보장하므로 유지 관리 가능하고 확장 가능한 코드를 만드는 데 중요합니다.

10장: ISP - 인터페이스 분리 원칙 ISP(Interface Segregation Principle)는 클라이언트가 사용하지 않는 인터페이스에 강제로 의존해서는 안 된다는 객체 지향 프로그래밍의 원칙입니다. 즉, 인터페이스는 이를 사용하는 클라이언트의 요구 사항에 따라 달라야 시간이 지남에 따라 시스템을 쉽게 변경하고 발전시킬 수 있습니다.

11장: DIP - 종속성 역전 원칙 DIP(Dependency Inversion Principle)는 상위 수준 모듈이 하위 수준 모듈에 의존해서는 안 되지만 둘 다 추상화에 의존해야 한다는 객체 지향 프로그래밍의 원칙입니다. 이 원칙은 다른 부분에 영향을 주지 않고 시스템의 모든 수준에서 변경할 수 있으므로 수정 및 확장이 쉬운 느슨하게 결합된 시스템을 만드는 데 중요합니다.

 

4부 컴포넌트 원칙

12장: 구성 요소 : 구성 요소는 독립적으로 개발, 배포 및 유지 관리할 수 있는 독립적인 소프트웨어 단위입니다. 그들은 종종 재사용이 가능하도록 설계되었으며 더 복잡한 시스템을 만들기 위해 결합될 수 있습니다. 구성 요소 기반 개발은 모듈성과 재사용을 강조하는 소프트웨어 개발에 대한 대중적인 접근 방식입니다.

13장: 구성 요소 응집력 : 구성 요소 응집력은 구성 요소의 일부가 전체 목적과 얼마나 밀접하게 관련되어 있는지를 측정합니다. 응집력이 높다는 것은 구성 요소의 일부가 밀접하게 관련되어 있고 특정 목표를 달성하기 위해 함께 작동한다는 것을 의미하는 반면, 응집력이 낮다는 것은 구성 요소의 일부가 느슨하게 관련되어 있어 함께 잘 작동하지 않을 수 있음을 의미합니다.

14장: 컴포넌트 결합 구성 요소 결합은 복잡한 소프트웨어 시스템을 구축하는 데 중요한 부분입니다. 구성 요소를 결합할 때 함께 작동하는 방식과 호환되는 인터페이스가 있는지 여부를 고려하는 것이 중요합니다. 이 프로세스는 복잡할 수 있으며 결과 시스템이 제대로 작동하고 유지 관리할 수 있도록 신중한 계획과 조정이 필요합니다.

5부 아키첵처

15장: 아키텍처란 무엇인가? 소프트웨어 아키텍처는 구성 요소, 관계 및 상호 작용을 정의하는 소프트웨어 시스템의 상위 수준 구조입니다. 아키텍처는 시스템 설계 및 구축을 위한 로드맵을 제공하고 결과 시스템이 의도한 목표 및 요구 사항을 충족하는지 확인하는 데 도움이 되기 때문에 중요합니다.

16장: 독립 독립성은 관심사의 분리와 구성 요소 간의 결합 감소를 촉진하는 소프트웨어 아키텍처의 핵심 원칙입니다. 독립성을 통해 구성 요소를 독립적으로 개발하고 유지 관리할 수 있으므로 시간이 지남에 따라 시스템을 쉽게 변경하고 발전시킬 수 있습니다.

17장: 경계: 선 그리기 경계는 서로 다른 구성 요소와 시스템 간의 상호 작용을 정의하기 때문에 소프트웨어 아키텍처의 중요한 부분입니다. 경계를 그리려면 시스템의 목표와 요구 사항은 물론 개발 및 운영에 영향을 미칠 수 있는 기술적 및 조직적 제약 조건을 신중하게 고려해야 합니다.

18장: 경계 해부 경계 구조는 시스템의 경계를 정의하는 구성 요소 및 인터페이스를 나타냅니다. 경계 구조를 이해하는 것은 시스템이 잘 정의되고 해당 구성 요소가 효과적으로 함께 작동하는지 확인하는 데 도움이 되기 때문에 중요합니다.

19장: 정책 및 수준 정책 및 수준은 시스템이 의도한 목표 및 요구 사항을 충족하는지 확인하는 데 도움이 되는 소프트웨어 아키텍처의 중요한 개념입니다. 정책은 시스템의 동작을 제어하는 ​​규칙과 지침을 정의하는 반면 수준은 시스템의 구성 요소와 기능을 구성하고 분류하는 방법을 제공합니다.

20장: 비즈니스 규칙 비즈니스 규칙은 비즈니스 또는 조직의 동작을 제어하는 ​​규칙 및 정책입니다. 비즈니스 규칙을 이해하는 것은 소프트웨어 아키텍트에게 중요한데, 결과 시스템이 비즈니스와 이해 관계자의 요구를 충족하는지 확인하는 데 도움이 되기 때문입니다.

21장: 샤우팅 아키텍처 샤우팅 아키텍처는 개발자, 설계자 및 비즈니스 이해 관계자를 포함한 다양한 이해 관계자 간의 커뮤니케이션 및 협업을 강조하는 소프트웨어 아키텍처에 대한 접근 방식을 설명하는 데 사용되는 용어입니다. 이 접근 방식은 결과 시스템이 모든 이해 관계자의 요구 사항을 충족하고 의도한 목적에 잘 맞는지 확인하는 데 도움이 될 수 있습니다.

22장: 클린 아키텍처 클린 아키텍처는 우려 사항의 분리와 서로 다른 구성 요소 및 계층 간의 잘 정의된 경계 사용을 강조하는 소프트웨어 아키텍처에 대한 접근 방식입니다. 이 접근 방식은 결과 시스템이 유연하고 유지 관리 가능하며 확장 가능하도록 하는 데 도움이 될 수 있습니다.

23장 프리젠터와 겸손한 객체 프리젠터와 겸손한 객체는 소프트웨어 시스템에서 비즈니스 로직을 프리젠테이션 로직과 분리하는 데 사용할 수 있는 디자인 패턴입니다. 이러한 패턴은 시스템이 잘 구성되고 유지 관리가 가능하며 시스템의 다른 부분에 영향을 주지 않고 변경이 이루어질 수 있도록 하는 데 도움이 될 수 있습니다.

24장: 부분적 경계 부분적 경계는 시스템을 독립적으로 개발하고 유지 관리할 수 있는 더 작고 관리하기 쉬운 구성 요소로 나누는 방법입니다. 이 접근 방식은 결과 시스템이 유연하고 수정하기 쉬운지 확인하는 데 도움이 될 수 있습니다.

 

25장(계속): 계층 및 경계 계층과 경계는 시스템의 구성 요소와 인터페이스를 구성하는 데 사용할 수 있는 소프트웨어 아키텍처의 두 가지 중요한 개념입니다. 레이어는 유사한 책임을 가진 구성 요소를 그룹화하는 방법이며 경계는 시스템의 서로 다른 부분 간의 인터페이스를 정의합니다.

26장: 주요 구성 요소 주요 구성 요소는 소프트웨어 시스템의 높은 수준의 빌딩 블록입니다. 이들은 시스템의 가장 중요한 부분이며 시스템의 핵심 기능 수행을 담당합니다. 주요 구성 요소를 이해하는 것은 시스템이 잘 구성되고 의도한 목표와 요구 사항을 충족하는지 확인하는 데 도움이 되기 때문에 소프트웨어 설계자에게 중요합니다.

27장: 크고 작은 서비스 서비스는 다양한 구성 요소와 시스템에 기능을 제공하는 데 사용할 수 있는 소프트웨어 시스템의 공통 아키텍처 패턴입니다. 서비스는 제공하는 기능의 범위와 복잡성에 따라 크거나 작을 수 있습니다. 서비스는 많은 최신 소프트웨어 시스템의 핵심 빌딩 블록이기 때문에 소프트웨어 설계자에게는 서비스를 이해하는 것이 중요합니다.

28장: 테스트 경계 테스트는 결과 시스템이 기능적이고 안정적이며 유지 관리 가능한지 확인하는 데 도움이 되는 소프트웨어 개발의 중요한 부분입니다. 테스트 경계는 제대로 함께 작동하는지 확인하기 위해 테스트해야 하는 시스템의 여러 부분 간의 인터페이스입니다. 테스트 경계를 이해하는 것은 시스템이 제대로 테스트되고 의도한 목표와 요구 사항을 충족하는지 확인하는 데 도움이 되므로 소프트웨어 설계자에게 중요합니다.

29장: 클린 임베디드 아키텍처 클린 임베디드 아키텍처는 일반적으로 다른 유형의 소프트웨어 시스템보다 더 작고 리소스가 더 제한된 임베디드 시스템용으로 설계된 소프트웨어 아키텍처에 대한 접근 방식입니다. 이 접근 방식은 모듈성, 단순성 및 리소스 효율성을 강조하며 결과 시스템이 안정적이고 유지 관리하기 쉬운지 확인하는 데 도움이 될 수 있습니다.

 

6부 세부사항

 

30장: 데이터베이스는 세부 정보입니다 데이터베이스는 많은 소프트웨어 시스템의 중요한 부분이지만 중앙 구성 요소가 아닌 세부 사항으로 취급되는 경우가 많습니다. 시스템에서 데이터베이스의 역할을 이해하고 이를 적절하게 설계하는 것은 시스템의 성능, 확장성 및 유지 관리 가능성에 상당한 영향을 미칠 수 있기 때문에 소프트웨어 설계자에게 중요합니다.

31장 웹은 디테일이다 웹은 소프트웨어 애플리케이션을 제공하기 위한 유비쿼터스 플랫폼이지만 중심 구성 요소가 아닌 세부 정보로 취급되는 경우가 많습니다. 웹 애플리케이션의 고유한 특성을 이해하고 적절하게 설계하는 것은 시스템의 사용성, 성능 및 보안에 상당한 영향을 미칠 수 있기 때문에 소프트웨어 설계자에게 중요합니다.

32장: 프레임워크는 세부사항입니다 프레임워크는 공통 작업을 단순화하고 복잡한 시스템 구축을 위한 기반을 제공하기 위해 소프트웨어 개발에 사용되는 공통 도구입니다. 그러나 프레임워크는 종종 중심 구성 요소가 아닌 세부 정보로 취급됩니다. 시스템에서 프레임워크의 역할을 이해하고 적절하게 선택하는 것은 시스템의 유지 관리 가능성, 유연성 및 성능에 상당한 영향을 미칠 수 있기 때문에 소프트웨어 설계자에게 중요합니다.

33장: 사례 연구: 비디오 판매 비디오 판매 사례 연구는 소프트웨어 아키텍처의 원칙과 개념이 실제 소프트웨어 시스템에 어떻게 적용될 수 있는지에 대한 예입니다. 이 사례 연구는 잘 설계된 아키텍처가 어떻게 이해 관계자의 요구 사항을 충족하면서 유연하고 확장 가능하며 유지 관리 가능한 시스템으로 이어질 수 있는지 보여줍니다.

34장: 누락된 장 누락된 장은 소프트웨어 개발에서 혁신과 창의성을 위한 여지를 남겨두는 것의 중요성을 설명하기 위해 책에서 의도적으로 생략한 것입니다. 이 장은 소프트웨어 개발 분야에서 배우고 발견할 것이 항상 더 많다는 것과 시스템을 설계하고 구축하는 데 단 하나의 "올바른" 방법은 없다는 생각을 나타냅니다.