클린아키텍쳐-정책과수준
정책과수준 소프트웨어 시스템이란 정책을 기술한것 동일한 이유로 동일한 시점에 변경되는 정책은 동일한 수준에 위치하며, 동일한 컴포넌트에 속해야 한다. 수준 수준을 엄밀하게 정의하자면 입력과 출력까지의 거리이다. 시스템의 임력과 출력 모두로부터 멀리 위치할수록 정책의 수준은 높아진다. 입력과 출력을 다루는 정책이라면 시스템
Writing
기술 자체보다 어떤 문제를 왜 그렇게 풀었는지에 초점을 둡니다.
정책과수준 소프트웨어 시스템이란 정책을 기술한것 동일한 이유로 동일한 시점에 변경되는 정책은 동일한 수준에 위치하며, 동일한 컴포넌트에 속해야 한다. 수준 수준을 엄밀하게 정의하자면 입력과 출력까지의 거리이다. 시스템의 임력과 출력 모두로부터 멀리 위치할수록 정책의 수준은 높아진다. 입력과 출력을 다루는 정책이라면 시스템
경계 해부학 경계 횡단하기 런타임에 경계를 횡단한다. 적절한 위치에서 경계를 횡단하게 하는 비결은 소스코드 의존성 관리에 있다. 두려운 단일체 아키텍처 경계 중에서 가장 단순하며 가장 흔한 형태는 물리적으로 엄격하게 구분되지 않는 형태다. 이 형태에선 함수와 데이터가 단일 프로세서에서 같은 주소 공간을 공유하며 그저 나름
선긋기(Boundaries) 소프트웨어 아키텍처는 선을 긋는 기술이며 이 선을 경계라 부른다. 관련이 있는 것과 없는 것 사이에 선을 긋는다. 경계는 변경의 축이 있는 지점에 그어진다. GUI와 업무 규칙과는 다른 시점에 다른 속도로 변경되므로 둘사이엔 반드시 경계가 필요하다. 단일 책임 원칙은 어디에 경계를 그어야 할지
독립성 좋은 아키텍처는 다음을 지원해야 된다. 시스템의 유즈케이스 시스템의 운영 시스템의 개발 시스템의 배포 유즈케이스 시스템의 아키텍처는 시스템의 의도를 지원해야 한다는 뜻이다. 운영 운영 관점에서는 덜 실질적이며 덜 피상적인 업무를 맡는다. 개발 시스템을 설계하는 조직이라면 어ㅣ뜬지 그 조직의 의사소통 구조와 동일한
아키텍처란? 소프트웨어 아키텍트는 프로그래머이며, 앞으로도 계속 프로그래머로 남는다. 아키텍처의 주된 목적은 시스템 생명주기를 지원하는 것이다. 시스템의 수명과 관련된 비용은 최소화하고, 프로그래머의 생산성은 최대화하는 데 있다. 개발 팀 구조가 다르다면 아키텍처 관련 결정에서도 차이가 난다. 일례로 팀이 개발자 다섯 명
컴포넌트 결합도 ADP: 의존성 비순환 원칙 컴포넌트 의존성 그래프에 순환이 있어서는 안된다. 숙취 증후군은 많은 개발자가 동일한 소스파일을 수정하는 환경에서 발생한다. 해결책으로 두가지 방법이 있다 주단위 빌드 의존성 비순환 원칙 주 단위 빌드 일주일에 4일동안은 서로를 신경쓰지 않다가 금요일날 변경된 코드를 통합하여
ASCIIDOCTOR PDF 변환 한글 spring rest docs 를 가지고 PDF로 변환하는데 한글이 깨진다. 이부분은 원래 부터 문제가 있었나보다. asciidoctor maven plugin 가지고 삽질중 플러그인 지식이 없으니 안됨 ㅜㅜ 그래서 아래링크 내용으로 작업을 진행 모두 인스톨후에 실행 변환 잘 되어서
컴포넌트 응집도 어떤 클래스는 어떤 컴포넌트에 포함시켜야 할까? REP : 재사용/릴리스 등가 원칙 CCP : 공통 폐쇄 원칙 CRP : 공통 재사용 원칙 REP : 재사용/릴리스 등가 원칙 재사용 단위는 릴리스 단위와 같다. 메이븐, 라이닝언, RVM 같은 모듈 관리 도구가 등장한 시기 이 기간에 재사용 가능한 컴포넌트
컴포넌트(Components) 컴포넌트는 배포 단위다. 컴포넌트는 시스템의 구성 요소로 배포할 수 있는 가장 작은 단위다. 잘설계된 컴포넌트라면 반드시 독립적으로 배포 가능한 따라서 독립적으로 개발 가능한 능력을 갖춰야 한다. 링킹 로더의 등장으로 프로그래머는 프로그램을 개별적으로 컴파일하고 로드 할수있는 단위로 분할할수
의존성 역전 원칙(DIP The Dependency Inversion Principle) 의존성이 추상에만 의존하며 구체에는 의존하지 않는 시스템 비현실적인 아이디어긴 하다. 자바 String은 구체 클래스이다. 이것을 추상클래스로 만들려는 시도는 없다 String은 매우 안정적이기 때문에 String 클래스가 변경되는일