클린 코드(Clean Code)/클린 아키텍처요약
-
20장 - 업무 규칙클린 코드(Clean Code)/클린 아키텍처요약 2023. 1. 12. 00:01
업무 규칙이란? 사업적으로 수익을 얻거나 비용을 줄일 수 있는 규칙 또는 절차입니다. 컴퓨터상으로 구현되었는지, 사람이 수동으로 직접 하는 것과는 연관이 없습니다. 보통 업무규칙은 데이터를 요구하며 이러한 데이터를 핵심 업무 데이터라 부릅니다. 핵심 규칙과 핵심 데이터는 본질적으로 결합되어 있기 때문에 객체로 만들 좋은 후보가 되며 이러한 유형을 엔티티라고 합니다. 엔티티 JPA등의 프레임워크를 다루며 엔티티는 친숙한 용어입니다. 예를 들어 대출을 뜻하는 Loan 엔티티는 다음과 같습니다 Loan 엔티티는 핵심 업무 데이터를 포함합니다. - 이율 - 기간 - 원칙 Loan 엔티티는 세 가지 핵심 업무 규칙을 인터페이스로 제공합니다. - makePayment - applyInterest - chargeLa..
-
19장 - 정책과 수준클린 코드(Clean Code)/클린 아키텍처요약 2023. 1. 2. 00:01
정책 소프트웨어 시스템이란 정책을 기술한 것입니다. 대다수의 주요 시스템에서 하나의 정책을 서술하는 여러 개의 조그만 정책들로 쪼갤 수 있습니다. 수준 수준이란 입력과 출력까지의 거리입니다. 시스템의 입력과 출력 모두로부터 멀리 위치할수록 정책의 수준은 높아집니다. 번역 컴포넌트는 이 시스템에서 최고 수준의 컴포넌트이며 입력과 출력에서 가장 멀리 떨어져 있습니다. 주목할 점은 데이터의 흐름과 소스코드의 의존성이 항상 같은 방향을 가리키지 않는다는 사실입니다. 소스 코드 의존성은 그 수준에 따라 결합되어야 하며, 데이터 흐름을 기준으로 결합되어서는 안 됩니다. 고수준인 Encrypt 함수가 저수준인 reader와 wrtier에 의존하면 안 됩니다. 회색 테두리 안에 묶인 영역이 이 시스템의 최고 수준의 구..
-
18장 - 경계 해부학클린 코드(Clean Code)/클린 아키텍처요약 2023. 1. 1. 00:01
개요 시스템 아키텍처는 일련의 소프트웨어 컴포넌트와 그 컴포넌트들을 분리하는 경계에 의해 정의됩니다. 이번 장에서는 이런 경계의 다양한 형태를 알아보려고 합니다. 경계 횡단하기 '경계를 횡단한다'함은 단순히 경계 한쪽에 있는 기능에서 반대쪽 기능을 호출하여 데이터를 전달하는 일에 불과합니다. 경계는 이러한 변경이 전파되는 것을 막는 방화벽을 구축하고 관리하는 수단으로써 존재합니다. 두려운 단일체 모놀리틱은 배포 관점에서 경계가 드러나지 않습니다. (하나의 거대한 파일이므로) 이에 모놀리틱은 다형성에 의존하여 내부 의존성을 관리합니다. 저수준 클라이언트와 고수준 서비스 고수준 클라이언트와 저수준 서비스 의존성 역전을 활용하여 컴파일 의존성과는 반대가 됩니다. 정적 링크된 모노리틱 구조의 실행 파일이라도 이..
-
17장 - 경계: 선 긋기클린 코드(Clean Code)/클린 아키텍처요약 2022. 12. 30. 00:01
경계란? 경계는 소프트웨어 요소를 서로 분리하고, 경계 한편에 있는 요소가 반대편에 있는 요소를 알지 못하도록 막습니다. 프로젝트 초기의 그어지는 선은 가능한 결정을 연기시키기 위한 목적으로 사용됩니다. W사, P사의 아키텍트가 너무 이르게 결정을 내려 개발 비용이 가중된 사례 이야기 Finesse 초기에 MySQL을 염두에 두고 있었으나 인터페이스와 스텁을 만들어두고 최대한 결정을 연기하였습니다. 이후에 영속성을 구현해야하는 시점에 MySQL을 다시 한번 고민하였으며, 단기적으로는 필요 없다는 결정을 내리게 되었으며 추후에는 완전히 폐기하였습니다. 하지만 추후에 고객이 MySql에 저장하고 싶다는 요구사항을 보였고, 하루 만에 도입할 수 있게 되었습니다. 이렇게 업무 규칙과 데이터베이스 사이에 경계선을..
-
16장 - 독립성클린 코드(Clean Code)/클린 아키텍처요약 2022. 12. 21. 00:01
좋은 아키텍트는 다음을 지원해야 합니다. - 시스템의 유스케이스 - 시스템의 운영 - 시스템의 개발 - 시스템의 배포 유스케이스 아키텍트는 시스템의 의도를 지원해야 합니다. 예를 들어 시스템이 장바구니 애플리케이션이라면 장바구니와 관련된 유스케이스를 지원해야 합니다. 만약 좋은 아키텍처를 갖춘다면 해당 시스템의 유스케이스는 시스템 구조 자체에서 한눈에 드러날 것입니다. 이들 행위는 일급 요소이며 시스템의 최상위 수준에서 알아볼 수 있으므로 개발자가 일일이 찾아 헤매지 않아도 됩니다. 운영 시스템이 초당 100,000명의 고객을 처리해야 한다면, 아키텍처는 이 요구와 관련된 각 유스케이스에 걸맞은 처리량과 응답 시간을 보장해야 합니다. 이런 형태를 지원하기 위한 시스템은 다양한 의미를 지닙니다. - 시스템..
-
15장 - 아키텍처란?클린 코드(Clean Code)/클린 아키텍처요약 2022. 12. 20. 00:01
아키텍처란? 아키텍처라는 단어는 권력과 신비로움을 연상케 합니다. 중대한 결정, 기술적 정취의 정점, 고수준의 문제에 집중해야 함 등이 떠오릅니다. 다른 프로그래머만큼 많은 작업은 하지 않을 수 있지만 아키텍트는 코드와 동떨어지면 안 됩니다. 아키텍처란 시스템을 컴포넌트로 분할하는 방법, 분할된 컴포넌트를 배치, 의사소통하는 방식에 따라 정해집니다. 가장 중요한 것은 아키텍처 안에 담긴 소프트웨어 시스템이 쉽게 개발, 배포, 운영, 유지보수되어야 합니다. 아키텍처의 목적으로 시스템의 동작도 중요하지만 주된 목적은 시스템의 생명주기를 지원하는 것입니다. 궁극적인 목표로 시스템의 수명과 관련된 비용은 최소화하고, 프로그래머의 생산성은 최대화해야 합니다. 개발 만약 5명 이내의 팀이라면 잘 정의된 컴포넌트, ..
-
14장 - 컴포넌트 결합클린 코드(Clean Code)/클린 아키텍처요약 2022. 12. 16. 00:01
컴포넌트 사이의 관계를 설명하는 세 가지 원칙을 다루고자 합니다. 의존성 비순환 원칙 컴포넌트 의존성 그래프에 순환이 있어서는 안 된다. 어떤 코드가 동작하는 것을 확인한 뒤, 다음날 출근해보면 작동하지 않는 경험이 있으신가요? 많은 개발자가 동일한 소스 파일을 수정하는 환경에서 발생하는 문제로 당신보다 더 늦게까지 일하면서 당신이 의존하고 있던 무언가를 수정해서 벌어진 일입니다. 이를 해결하기 위한 두 가지 방법이 발전되어 왔습니다. 주 단위 빌드 4일은 개발자들이 개별 작업 , 1일은 통합하는데 시간을 소요합니다. 하지만 프로젝트의 덩치가 커질수록 통합하는 작업을 하루가 아니라 더 소모됩니다. 점점 개발팀의 통합 효율성은 낮아지고 빌드 일정은 늘어나며 프로젝트가 감수할 위험은 커집니다. 순환 의존성 ..
-
13장 - 컴포넌트 응집도클린 코드(Clean Code)/클린 아키텍처요약 2022. 12. 14. 00:01
어떤 클래스를 어떤 컴포넌트에 포함시켜야 할까요? 이 장에서는 컴포넌트 응집도와 관련된 세 가지 원칙을 논합니다 REP: 재사용/릴리스 등가 원칙 CCP: 공통 폐쇄 원칙 CRP: 공통 재사용 원칙 Reuse/Release Equivalence Principle(REP) : 재사용/릴리스 등가 원칙 재사용 단위는 릴리스 단위와 같다. 지난 십 년은 메이븐, 라이닝언, RVM 같은 모듈 관리 도구가 많이 생겼습니다. 이 기간에는 재사용 가능한 컴포넌트가 컴포넌트 라이브러리가 엄청나게 많이 만들어졌기 때문입니다. 소프트웨어 컴포넌트가 릴리즈 절차를 통해 추적 관리되지 않거나 릴리스 번호가 부요되지 않는다면 해당 컴포넌트를 재사용하고 싶어도 할 수도 없고, 하지도 않을 것입니다. 릴리스 번호가 없다면 재사용 ..