feel_2

Ch30. 데이터베이스는 세부사항이다.아키텍처 관점에서 볼 때 데이터베이스는 엔티티가 아니다.즉, 데이터베이스는 세부사항이라서 아키텍처의 구성요소 수준으로 끌어올릴 수 없다.데이터베이스는 일개 소프트웨어이며, 데이터에 접근할 방법을 제공하는 유틸리티다. 이러한 유틸리티는 저수준의 세부사항(메커니즘)일 뿐이라서 아키텍처와는 관련이 없다. [관계형 데이터베이스]관계형 데이터베이스는 세부사항이다.관계형 테이블은 특정한 형식의 데이터가 접근하는 경우에는 편리하지만, 데이터를 테이블에 행 단위로 배치한다는 자체는 아키텍처적으로 볼 때 전혀 중요하지 않다.애플리케이션의 유스케이스는 이러한 방식을 알아서는 안되며 관여해서도 안 된다. 많은 데이터 접근 프레임워크가 테이블과 행이 객체 형태로 시스템 여기저기에서 돌아다..

Ch25. 계층과 경계시스템이 세 가지 컴포넌트(UI, 업무 규칙, 데이터베이스)로만 구성된다고 생각하기 쉽다.단순한 시스템이라면 그렇지만, 대다수의 시스템에서 컴포넌트의 개수는 이보다 훨씬 많다. [움퍼스 사냥 게임]컴퓨터 게임 예제에 살을 좀 붙여보자.텍스트를 기반으로 하는 움퍼스라는 게임은 GO EAST와 SHOOT WEST와 같은 매우 단순한 명령어를 사용한다.플레이어는 명령어를 입력하면 컴퓨터는 플레이어가 보고, 냄새 맡고, 듣고, 경험할 것들로 응답한다. 만약 이 게임을 다양한 언어로 발매할 수 있게 만든다고 가정해보자.그럼 이러한 구조로 만들면 게임 규칙이 어떤 언어를 사용하던, 어떤 저장소를 사용하던 상관 없이 모두 적용할 수 있다. [클린 아키텍처?]분명하게도 이 예제의 맥락이라면 클린..

Ch20. 업무 규칙애플리케이션을 업무 규칙과 플러그인으로 구분하려면 업무 규칙이 실제로 무엇인지를 잘 이해해야 한다.엄밀하게 말하면 업무 규칙은 사업적으로 수익을 얻거나 비용을 줄일 수 있는 규칙 또는 절차다. 대출에 N%의 이자를 부과한다는 사실은 은행이 돈을 버는 업무 규칙이다.이러한 사실은 컴퓨터 프로그램으로 이자를 계산하든, 또는 직원이 주판을 튕겨 계산하든 아무상관 없다. 이러한 규칙을 핵심 업무 규칙이라고 한다.왜냐하면 이들 규칙은 사업 자체에 핵심적이며, 규칙을 자동화하는 시스템이 없더라도 업무 규칙은 그대로 존재하기 때문이다.핵심 업무 규칙은 보통 데이터를 요구한다. 예를 들어 대출에는 대출 잔액, 이자율, 지급 일정이 필요하다.이러한 데이터를 우리는 핵심 업무 데이터라고 부르겠다. 핵심..

Ch15. 아키텍처란? 아키텍처라는 단어는 권력과 신비로움을 연상케 한다.소프트웨어 아키텍처는 기술적 성취의 정점에 서 있다. 무엇보다도 소프트웨어 아키텍트는 프로그래머이며, 앞으로도 게속 프로그래머로 남는다.소프트웨어 아키텍트라면 코드에서 탈피하여 고수준의 문제에 집중해야 한다는 거짓말에 속아넘어가서는 안 된다. 소프트웨어 아키텍트는 최고의 프로그래머이며, 앞으로도 계속 프로그래밍 작업을 맡을 뿐만 아니라 동시에 나머지 팀원들이 생산성을 극대화할 수 있는 설계를 하도록 방향을 이끌어 준다. 소프트웨어 시스템의 아키텍처란 시스템을 구축했던 사람들이 만들어내 시스템의 형태다. 그리고 그 형태는 아키텍처 안에 담긴 소프트웨어 시스템이 쉽게 개발, 배포, 운영, 유지보수되도록 만들어진다. 이러한 일을 용이하게..

Ch12. 컴포넌트 컴포넌트는 배포 단위다. 컴포넌트는 시스템의 구성 요소로 배포할 수 있는 가장 작은 단위다. 각 언어별 컴포넌트 단위를 보면Java : jar루비: gem닷넷: DDL모든 언어에서 컴포넌트는 배포할 수 있는 단위 입자다. 여러 컴포넌트를 서로 링크하여 실행 가능한 단일 파일로 생성할 수 있다. 또는 여러 컴포넌트를 서로 묶어서 .war 파일과 같은 단일 아카이브로 만들 수도 있다. 컴포넌트가 마지막에 어떤 형태로 배포되든, 잘 설계된 컴포넌트라면 반드시 독립적으로 배포 가능한, 따라서 독립적으로 개발 가능한 능력을 갖춰야 한다. [컴포넌트의 간략한 역사]소프트웨어 개발 초창기에는 메모리에서의 프로그램 위치와 레이아웃을 프로그래머가 직접 제어했다.따라서 로드할 메모리의 위치를 정하는 일..

Ch7. SRP: 단일 책임 원칙 SOLID 원칙 중에서 그 의미가 가장 잘 전달되지 못한 원칙은 바로 단일 책임 원칙이다.역사적으로 SRP는 아래와 같이 기술되어 왔다. 단일 모듈은 변경의 이유가 하나, 오직 하나뿐이어야 한다. 소프트웨어 시스템은 사용자와 이해관계자를 만족시키기 위해 변경된다.SRP에서 말하는 ‘변경의 이유’란 바로 이들 사용자와 이해관계자를 가리킨다.좀더 명확한 SRP의 최종 버전은 아래와 같다.하나의 모듈은 하나의, 오직 하나의 액터에 대해서만 책임져야 한다. 그럼 ‘모듈’이란 또 무슨 뜻인가? 가장 단순한 정의는 바로 소스 파일이다.대부분의 경우 이 정의는 잘 들어 맞는다. ‘응집된’이라는 단어가 SRP를 암시한다. 단일 액터를 책임지는 코드를 함께 묶어주는 힘이 바로 응집성이다..

여러 가지 의미로, 함수형 프로그래밍이라는 개념은 프로그래밍 그 자체보다 앞서 등장했다.패러다임에 핵심이 되는 기반은 람다 계산법으로, 알론조 처치가 1930년대에 발명했다. [정수를 제곱하기]함수형 프로그래밍이 무엇인지 설명하려면 몇 가지 사례를 보여주는게 가장 좋다. 25까지의 정수의 제곱을 출력하는 간단한 문제를 다뤄보자.먼저 자바 언어라면 아래와 같이 작성이 가능하다.public class Squint { public static void main(String args[]) { for (int i = 0; i 리스프에서 파생한 클로저는 함수형 언어로, 클로저를 이용하면 같은 프로그램을 다음과 같이 구현할 수 있다.(println (take 25 (map (fn [x] (* x x)) (r..

나중에 살펴보겠지만, 좋은 아키텍처를 만드는 일은 객체 지향(Object-Oriented, OO) 설계 원칙을 이해하고, 응용하는데서 출발한다.그렇다면 대체 OO는 무엇인가? 이 질문에 대해 누군가는 “데이터와 함수의 조합”이라고 답할 수 있다.대체로 이런 방식으로 많이 설명되지만, 그다지 만족스러운 대답은 아니다.또한 이 질문에 흔히 “실제 세계를 모델링하는 새로운 방법”이라고들 답한다. 이는 기껏해야 얼버무리는 수준에 지나지 않는다. OO의 본질을 설명하기 위해 세 가지 주문에 기대는 부류도 있는데,캡슐화상속다형성이다. 이제 이들 세 가지 개념을 차례대로 살펴보자. [캡슐화]OO를 정의하는 요소 중 하나로 캡슐화를 언급하는 이유는 데이터와 함수를 쉽고 효과적으로 캡슐화하는 방법을 OO 언어가 제공하기..

에츠허르 비버 데이크스트라는 1930년에 로테르담에서 태어났다.데이크스트라는 최초로 자신을 ‘프로그래머’라는 직업 명칭을 썼으며, 암스테르담의 수학센터에 취업한다. 데이크스트라는 진공관 시대에 자신의 경력을 시작했는데, 이 시대는 컴퓨터가 거대하고, 쉽게 손상되며, 느린 데다가 결과마저 믿을 수 없는, 그래서 극도로 제한적으로만 사용될 때였다. 이 초창기에는 프로그램을 바이너리로 또는 매우 투박한 기계어를 이용해서 작성했다.데이크스트라는 이처럼 원시적인 환경에서 위대한 발견을 해냈다. [증명]데이크스트라가 초기에 인식한 문제는 프로그래밍은 어렵고, 프로그래머는 프로그래밍을 잘하지 못한다는 사실이다.데이크스트라는 증명이라는 수학적인 원리를 적용하여 이 문제를 해결하고 하였다. 데이크스트라는 이 연구를 진행..

이 장에서는 세 가지 패러다임인 구조적 프로그래밍, 객체지향 프로그래밍, 함수형 프로그래밍에 대해 설명한다. [구조적 프로그래밍]최초로 적용된 패러다임(하지만 최초로 만들어진 패러다임은 아닌)은 구조적 프로그래밍이다.1968년 에츠허르 비버 데이크스티라가 발견했으며, 무분별한 점프(goto 문장)는 해롭다는 사실을 제시했다. 구조적 프로그래밍은 제어흐름의 직접적인 전환에 대해 규칙을 부과한다. [객체 지향 프로그래밍]두 번째로 도입된 패러다임은 구조적 프로그래밍보다 사실 2년 앞선 1966년, 요한 달과 크리스텐 니가드에 의해 등장했다. 이들 두 프로그래머는 알골 언어의 함수 호출 스택 프레임을 힙으로 옮기면, 함수 호출이 반환된 이후에도 함수에서 선언된 지역 변수가 오랫동안 유지될 수 있음을 발견했다...