삶은달걀노른자

■ 31장 웹은 세부사항이다 The Web Is a Detail ​ 웹은 GUI 이므로 아키텍처에서 업무로직과 분리되어야 하는 세부사항이다. ​ 물론 웹은 너무 특이해서 장치 독립적인 아키텍처를 추구하는 것이 어렵다는 것을 저자도 어느정도 인정은 한다. 다만 UI와 어플리케이션 사이에 존재하는 또다른 추상화 경계인 유스케이스가 어느정도 완충작용을 할 수 있으리라 본다. ​ ​

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

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

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