삶은달걀노른자

■ 17장 경계: 선 긋기 Boundaries: Drawing Lines ​ 업무 요구사항(유스케이스)과 아무 관련이 없는 결정사항들, 이를테면, 프레임워크, 데이터베이스, 웹서버, 유틸리티 라이브러리, 의존성 주입 같은 것들은 결정을 최대한 뒤로 미뤄야 한다. 이러한 부수적인 것들이 빨리 결정될수록 제약이 많이 생기게 되며, 그렇게 되면 관련된 문제들과 일찍, 많이 맞닥뜨리게 된다. ​ 경계(선, Boundary)는 관련이 있는 것과 없는 것 사이에 그어야 하는데, 가령 GUI나 DB의 경우는 업무규칙과는 관련이 없으므로 이들 사이에 경계가 필요하다. ​ 아래 그림과 같이 DB와 GUI가 업무규칙을 참조하므로 이들이 업무규칙에 의존성을 가지고 있는 것이며, 이는 업무규칙은 DB와 GUI가 무엇이 되든(..

​■ 16장 독립성 Independence ​ 잘 격리되어 독립적으로 개발 가능한 컴포넌트 단위로 시스템을 분할해야 한다. 쉽게 말하면, UI, 업무로직, DB 계층을 횡단으로 분리하고, 유스케이스를 종단으로 분리하여 씨줄과 날줄이 엮이는 패턴을 만들 수 있다. 이를 통해 개발 독립성과 배포 독립성을 얻을 수 있다. ​ 계층과 유스케이스를 분리하는 방법은 소스 수준, 배포 수준, 서비스 수준의 분리가 있다. 서비스 수준의 분리가 가장 좋긴 하지만 고비용의 문제가 있기 때문에 일단 컴포넌트 단위까지 분리하고 추후 서비스 수준의 분리가 가능하도록 가능성을 열어 두는 것이 현실적으로 적합하다. ​ ​ ​

◆ Part 5 아키텍처 Architecture ​ ■ 15장 아키텍처란? What Is Architecture? ​ 아키텍처의 주된 목적은 시스템의 생명주기를 지원하는 것이다. 아키텍처의 궁극적인 목표는 시스템의 수명과 관련된 비용은 최소화하고, 프로그래머의 생산성은 최대화하는 데에 있다. ​ 좋은 아키텍트는 세부사항을 정책으로부터 분리해 내고 어떤 경우라도 정책이 세부사항에 의존하지 않도록 하는 것이다. 정책은 업무의 규칙과 절차이며, 세부사항은 입출력 장치 DB, 웹시스템, 서버, 프레임워크, 통신 프로토콜 등을 말한다. ​ ​ ​

■ 11장 DIP: 의존성 역전 원칙 Dependency Inversion Principle ​ 유연성이 극대화된 시스템 = 소스코드 의존성이 추상 abstraction 에 의존하며 구체 concretion 에는 의존하지 않는 시스템이다. 의존을 피해야 하는 것은 변동성이 큰 volatile 구체적인 요소이다. 이 구체적인 요소는 한창 개발중이라 자주 변경될 수밖에 없는 모듈이라고 할 수 있다. 쉽게 말해 구체인 class가 추상인 interface를 참조하는 모습을 생각하면 된다. ​ - 변동성이 큰 구체 클래스를 (직접)참조하지 말 것. 대신 추상 팩토리 Abstract Factory 를 사용한다. - 변동성이 큰 구체 클래스로부터 파생(상속)하지 말 것. - 구체 함수를 오버라이드 override ..

■ 8장 OCP: 개방-폐쇄 원칙 Open-Closed Principle ​ 객체는 확장에는 열려 있어야 하고(개방), 변경에는 닫혀 있어야 한다.(폐쇄) 변경되는 코드의 양을 최소화 하기 위해서는, 서로 다른 목적으로 변경되는 요소를 적절하게 분리하고(단일책임원칙 SRP), 이들 요소 사이의 의존성을 체계화(의존성역전원칙 DIP)해야 한다. ​ ​ 위 그림에서 화살표 A -> B는 소스코드 의존성의 방향으로 A에서 B를 호출한다는 뜻이다. 컴포넌트 관계는 단방향으로만 이루어져야 하는데, 화살표의 방향은 변경으로부터 보호하려는 컴포넌트를 향하고 있다. A에서 발생한 변경으로부터 B를 보호하려면 A가 B에 의존해야 한다. (즉, A -> B) ​ 위에서 우측 상단의 Interactor는 업무규칙을 포함하므..

◆ Part 3 설계 원칙 Design Principles ​ 좋은 시스템은 깔끔한 코드로부터 시작되며 이를 가능하게 하는 아키텍처 원칙이 SOLID이다. 이 원칙의 목적은 중간 수준의 소프트웨어 구조를 잘 만드는 데에 있다. 중간 수준이라 함은 코드 수준보다는 조금 상위에서 적용할 수 있다는 말이며, 모듈과 컴포넌트 내부에서 사용되는 소프트웨어 구조를 정의하는 데 도움을 준다. ​ SOLID는 다음의 다섯 가지 원칙이다. ​ - SRP : Single Responsibility Principle / 단일 책임 원칙 - OCP: The Open-Closed Principle / 개방-폐쇄 원칙 - LSP: The Liskov Substitution Principle / 리스코프 치환 원칙 - ISP: T..

◆ Part 2 벽돌부터 시작하기: 프로그래밍 패러다임 Starting with the Bricks: Programming Paradigms 여기서 벽돌은 소스코드를 말한다. 집을 짓을 때 기초가 되는 재료가 벽돌이듯이 소프트웨어 개발의 기초인 코드부터 이야기를 시작한다는 말이다. ■ 3장 패러다임 개요 Paradigm Overview 수십 년 간 프로그래밍 패러다임에 혁신적인 변화가 몰아쳤는데 대체로 언어에는 독립적이다. 패러다임은 어떤 프로그래밍 구조를 사용할지, 언제 사용할지를 결정하는 것으로 현재까지는 3가지 외에는 존재하지 않는다. - 구조적 프로그래밍 Structured programming - 객체지향 프로그래밍 Object-oriented programming - 함수형 프로그래밍 Func..

■ 2장 두 가지 가치에 대한 이야기 여기서 두 가지 가치란 행위 behavior 와 구조 structure 이다. 행위는 개발자가 코드를 작성하고 디버깅하는 것을 말하며 보통 프로그래머는 이 활동이 자신의 일의 전부라고 생각하지만 틀린 생각이다. 소프트웨어는 말 그대로 soft 하기 때문에 변경이 자주 발생한다. 이러한 변경사항을 적용하는 데 드는 어려움은 변경되는 범위 scope 에 비례해야 하며 형태 shape 와는 관련이 없어야 한다. 새로운 요구사항이 발생할 때마다 적용하는 것이 더 힘들어지는데, 이것은 시스템의 형태와 요구사항의 형태가 서로 맞지 않기 때문이다. 개발자는 사각형 마개를 동그란 구멍에 밀어 넣도록 강요하는 느낌(다른 형태에 억지로 넣는 느낌)을 받는다. 여기서 중요한 것이 아키텍..

클린 아키텍처 Clean Architecture Robert C. Martin ◆ Part 1 소개 프로그램이 동작하도록 만드는 것은 그리 어렵지 않지만 제대로 만드는 것은 어려운 일이다. 제대로 된 소프트웨어를 만들면 유지보수에 적은 인력만이 필요하고 변경 또한 단순하고 빨라진다. 결함은 적어지고 유연성은 최대화된다. ■ 1장 설계와 아키텍처란? What Is Design and Architecture? 설계 design 와 아키텍처 architecture 는 사실 아무 차이가 없다(고 저자는 주장한다). 아키텍처는 저수준의 세부사항과는 분리된 고수준의 무언가를 가리킬 때 주로 사용하고, 설계는 저수준의 구조 및 결정사항을 의미할 때가 많다. 아키텍트가 하는 일을 보면 이 둘을 구분하는 것은 무의미하다..