소개 클린아키텍처: 소프트웨어 구조와 설계의 원칙 책을 읽고 정리하며 소감을 적는 포스트입니다. 아키텍처란? 아키텍처(architecture)라는 단어는 권력과 신비로움을 연상케 한다. 소프트웨어아키텍처는 기술적 성취의 정점에 서 있다. 소프트웨어 아키텍트를 생각할 때면, 권한을 가지며 존경심을 불러일으키는 사람을 떠올린다. 그러면 소프트웨어 아키텍처란 무엇인가? 소프트웨어 아키텍트는 무슨 일을 하며, 언제 그 일을 하는가? 무엇보다도 소프트웨어 아키텍트는 프로그래머이며, 앞으로도 계속 프로그래머로 남는다. 소프트웨어 아키텍트라면 코드에서 탈피하고 고수준의 문제에 집중해야 한다는 거짓말에 절대로 속아서는 안된다. 소프트웨어 아키텍트는 최고의 프로그래머이며, 앞으로도 계속 프로그래밍 작업을 맡을 뿐만 아니..

소개 클린아키텍처: 소프트웨어 구조와 설계의 원칙 책을 읽고 정리하며 소감을 적는 포스트입니다. 컴포넌트 결합 지금 부터 다룰 세 가지 원칙은 컴포넌트 사이의 관계를 설명한다. 개발 가능성과 논리적 설계 사이의 균형을 다룬다. 컴포넌트 구조와 관련된 아키텍처를 침번하는 힘은 기술적이며, 정치적이고, 가변적이다. ADP: 의존성 비순환 원칙 컴포넌트 의존성 그래프에 순환(cycle)이 있어서는 안 된다. 하루 종일 일해서 무언가를 작동하게 만들고 퇴근 했는데, 이튿날 전혀 돌아가지 않는 경험을 해본적 있는가? 누군가 당신보다 더 늦게까지 일하며 의존하고 있던 무언가를 수정했기 때문이다. 나는 이러한 현상을 숙취 증후군(the morning after syndrome)이라고 부른다. 프로젝트의 규모가 커지면..

소개 클린아키텍처: 소프트웨어 구조와 설계의 원칙 책을 읽고 정리하며 소감을 적는 포스트입니다. 컴포넌트 응집도 어떤 클래스를 어느 컴포넌트에 포함시켜야 할까? 이 장에서는 컴포넌트 응집도와 관련된 세 가지 원칙을 논의한다. REF : 재사용/릴리스 등가원칙(Reuse/Release Equivalence Principle) CCP : 공통 폐쇄 원칙(Commom Closure Principle) CRP : 공통 재사용 원칙(Common Reuse Principle) REP: 재사용/릴리스 등가 원칙 재사용 단위는 릴리스 단위와 같다. 우리는 이제 소프트웨어 재사용의 시대에 살고 있다. 객체 지향 모델의 오랜 약속 중 하나가 실현되었다. 돌이켜 보면 재사용/릴리스 등가 원칙(REP)는 너무 당연하다. 릴리..

소개 클린아키텍처: 소프트웨어 구조와 설계의 원칙 책을 읽고 정리하며 소감을 적는 포스트입니다. 컴포넌트 원칙 컴포넌트는 배포 단위다. 컴포넌트는 시스템의 구성 요소로 배포할 수 있는 가장 작은 단위다. 자바에서는 jar 파일이 컴포넌트이고, 닷넷에서는 DLL이다. 컴포넌트가 가장 마지막에 어떤 형태로 배포되든, 잘 설계된 컴포넌트라면 반드시 독립적으로 배포 가능한, 따라서 독립적으로 개발 가능한 능력을 갖춰야 한다. 컴포넌트의 간략한 역사 소프트웨어 개발 초창기에는 메모리에서의 프로그램 위치와 레이아웃을 프로그래머가 직접 제어했다. 프로그램의 시작부에는 프로그램이 로드 될 주소를 선언하는 오리진(origin) 구문이 나와야 했다. *200 TLS START, CLA TAD BUFR JMS GETSTR ..

소개 클린아키텍처: 소프트웨어 구조와 설계의 원칙 책을 읽고 정리하며 소감을 적는 포스트입니다. DIP: 의존성 역전 원칙 의존성 역전 원칙에서 말하는 '유연성이 극대화된 시스템'이란 소스 코드 의존성이 추상(abstraction)에 의존하며 구체(concretion)에는 의존하지 않는 시스템이다. 자바 같은 정적 타입 언어에서는 이 말은 use, import, include 구분이 오직 인터페이스나 추상 클래스 같은 추상적인 선언만을 참조해야 한다는 뜻이다. 구체적인 대상에는 절대로 의존해서는 안된다. 루비나 파이썬 같은 동적 타입에도 소스 코드 의존 관계에서 구체 모듈은 참조해서는 안된다. 하지만 String 같은 클래스는 구체 클래스이며, 이를 의존하지 않기는 어렵다. 반면 String 클래스는 변..

소개 클린아키텍처: 소프트웨어 구조와 설계의 원칙 책을 읽고 정리하며 소감을 적는 포스트입니다. ISP: 인터페이스 분리 원칙 인터페이스 분리 원칙은 아래의 다이어그램에서 그 이름이 유래했다. 인터페이스 분리 원칙 User1은 오직 op1을 User2는 op2만을, User3는 op3만을 사용한다고 가정한다. 이 경우 User1은 op2와 op3를 전혀 사용하지 않음에도 User1의 소스코드는 이 두 메서드에 의존하게 된다. 이러한 의존성으로 인해 op2가 수정되면 User1도 다시 컴파일 후 새로 배포해야 한다. 그래서 아래와 같인 인터페이스를 분리해여 관리 하여야 한다. 분리된 오퍼레이션 ISP와 언어 앞에서 본 사례는 언터 타입에 의존한다. 정적 타입 언어는 사용자가 import, use 또는 in..