삶은달걀노른자

■ 23장 프레젠터와 험블 객체 Presenters and Humble Objects ​ 기본적인 본질은 남기고 테스트하기 어려운 행위만 옮겨놓은 것을 험블 humble 객체라고 한다. GUI 영역을 프레젠터와 뷰로 분리할 때 뷰에 해당하는 것이 험블이다. ​ ** Humble의 사전적 의미는 '겸손한', '변변찮은' 등이 있는데, 여기서는 '변변찮은' 혹은 '중요하지 않은'의 의미로 해석하면 될 것 같다. 'humble' : 네이버 사전 검색결과 33종 언어사전과 방대한 지식백과를 제공 dict.naver.com 프레젠터 Presenter 는 데이터를 받아 화면에 표현할 수 있는 포맷으로 만드는 역할을 한다. 가령 Date 객체를 전달받아 적절한 문자열로 만들고 이를 View model 이라고 부르는 ..

■ 22장 클린 아키텍처 Clean Architecture ​ 다양한 시스템 아키텍처가 있지만 이들의 공통된 목표는 ‘관심사의 분리’이다. 최소한 하나의 업무규칙 계층과 인터페이스 및 그밖의 다른 계층으로 분리해야 한다. ​ 또한 다음의 특징을 지닌다. ​ 프레임워크 독립성 : 업무규칙은 프레임워크에 의존하지 않으며 단지 그것을 도구로 사용할 수 있어야 한다. 테스트 용이성 : 업무규칙은 UI나 데이터베이스, 웹 서버 등의 외부 요소가 없이도 테스트 될 수 있어야 한다. UI 독립성 : 업무규칙을 변경하지 않고 UI를 바꿀 수 있어야 한다. 데이터베이스 독립성 : 업무규칙을 변경하지 않고 DBMS를 바꿀 수 있어야 한다. 모든 외부 에이전시에 대한 독립성 : 업무규칙은 외부 세계의 인터페이스에 대해 전혀..

■ 21장 소리치는 아키텍처 Screaming Architecture ​ 집의 설계도를 보고 이건 집이야 라고 소리칠 수 있고, 도서관의 설계도를 보고 이건 도서관이야 라고 소리칠 수 있듯이 소프트웨어의 아키텍처 역시 이건 헬스케어 시스템이야 혹은 이건 재고관리 시스템 이야 하고 소리칠 수 있어야 한다. ​ 이렇게 하기 위해서는 소프트웨어 아키텍처는 유스케이스가 중심이 되어야 한다. 프레임워크, 데이터베이스, 웹 서버, 기타 개발환경이나 도구는 변두리의 지엽적인 문제로 이들은 최대한 뒤로 결정을 미룰 수 있어야 한다. ​ 웹은 전달 메커니즘(입출력 장치)일 뿐 아키텍처 자체는 아니다. 따라서 아키텍처는 시스템을 웹으로 할지, 앱으로 할지, 또는 C/S로 할지에 대한 결정을 최대한 뒤로 미뤄야 한다. 프레..

■ 20장 업무규칙 Business Rules 어플리케이션을 업무규칙과 플러그인으로 구분해 보자. ​ 업무규칙에는 컴퓨터 상으로 구현했는지와 상관없이 사업적으로 정의된 핵심 업무 규칙이 있다. 이것은 사람이 수동으로 실행하더라도 유효해야 한다. 가령 대출에 n% 이자를 부과한다는 것 등이 될 수 있다. 업무규칙은 핵심 규칙과 핵심 데이터를 가지고 있으며 이는 엔티티로 표현된다. ​ 반면 시스템의 자동화된 동작을 통해 정의되는 업무 규칙도 있는데, 신규 대출을 위해 사용자로부터 정보를 입력받아 신용도를 자동 계산하고 이를 통해 대출을 승인할지 거절할지 결정하는 업무라면 이는 핵심 업무규칙은 아니지만 유스케이스로 분류된다. 유스케이스는 자동화된 시스템이 사용되는 방법을 설명한다. ​ 엔티티는 자신을 제어하는..

■ 19장 정책과 수준 Policy and Level ​ 소프트웨어 시스템은 정책을 기술한 것이고, 정책이 프로그램 핵심부의 전부라고 할 수 있다. ​ 정책에는 집계와 관련된 업무규칙을 처리하는 방식을 서술하는 것과 특정 보고서를 어떤 포맷으로 만들지를 서술하는 것, 입력 데이터를 어떻게 검증할지를 서술하는 것 등이 있을 수 있다. ​ 또한 수준이란 ‘입력과 출력까지의 거리’를 말한다. 입력과 출력 모두로부터 멀수록 정책의 수준은 높아진다. 좋은 아키텍처는 각 컴포넌트를 연결할 때 의존성의 방향이 저수준에서 고수준을 의존하도록 설계되어야 한다. ​ 아래 그림에서 Translate 컴포넌트는 입력과 출력에서부터 멀리 떨어져 있기 때문에 수준이 최고로 높다. 소스코드의 의존성은 점선의 방향이다. 모든 소스코..

■ 18장 경계 해부학 Boundary Anatomy ​ 경계의 예로는 단일체(monolith), 배포형 컴포넌트, 스레드, 로컬 프로세스, 서비스 정도가 있다. ​ 1. 단일체는 그냥 통으로 된 하나의 소프트웨어로 보면 된다. 그래서 사실상 물리적인 경계가 잘 드러나지 않는다. ​ 2. 배포형 컴포넌트는 dll, jar, gem, 유닉스 공유 라이브러리 등으로 배포 과정만 차이가 날 뿐 단일체와 동일하다. ​ 3. 스레드는 하나의 컴포넌트에 포함될 수도 있고 여러 컴포넌트에 분산될 수도 있으므로 사실 경계라고 할 수는 없다. (실행계획과 순서를 체계화하는 방법에 가깝다고 함) ​ 4. 로컬 프로세스는 각각 독립된 주소 공간에서 실행되므로 물리적 경계가 비교적 뚜렷하다. ​ 5. 서비스가 물리적으로 가장..

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

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

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

■ 14장 컴포넌트 결합 Component Coupling ​ 컴포넌트 사이의 관계에 관련 3가지 원칙은 아래와 같다. ​ 1. 의존성 비순환 원칙 ADP: Acyclic Dependencies Principle 2. 안정된 의존성 원칙 SDP: Stable Dependencies Principle 3. 안정된 추상화 원칙 SAP: Stable Abstractions Principle ​ 1. 의존성 비순환 원칙 Acyclic Dependencies Principle, ADP 컴포넌트 간의 의존성 그래프는 순환되어서는 안 된다. 순환을 제거하기 위해서는 사이에 인터페이스를 만들어서 의존성 역전 원칙 DIP를 적용해야 한다. ​ 2. 안정된 의존성 원칙 Stable Dependencies Principle..