시스템의 아키텍처는의존성 규칙을 준수하며 고수준의 정책을 저수준의 세부사항으로부터 분리하는 경계에 의해 정의됨. 단순히 애플리케이션의 행위를 서비스 단위로 나누는 것(서비스 기반 아키텍처)은, 서비스 간 협력이 필요할 때 함수 호출 비용만 증가시키는 결과를 낳을 수 있음.서비스 기반 아키텍처에 대한 오해확장 가능한 시스템 = 서비스 기반 시스템이라는 등식은 성립하지 않음.모놀리식 기반 시스템도 대규모 시스템에 적합함을 입증한 기업들이 있음서비스는 항상 독립적으로 배포되지 않음.데이터나 로직이 강하게 결합된 경우, 해당 서비스들은 함께 개발·배포되어야 함서비스 기반 Taxi 호출 아키텍처Taxi Supplier외부 택시 공급자 시스템 혹은 파트너사에서 실시간으로 택시 위치, 상태, 차량 정보 등을 제공Ta..

메인 컴포넌트란메인 컴포넌트는 main() 함수가 존재하는 객체이며, 시스템의 초기 진입점이다.모든 시스템에는 최소한 하나의 메인 컴포넌트가 존재해야 하며, 클린 아키텍처 관점에서 보면 가장 바깥 원에 위치한 모듈이다.= 운영체제를 제외하면, 어떤 것도 메인에 의존하지 않는다. 메인 컴포넌트의 책임메인 컴포넌트는 다음과 같은 일들을 수행해야 한다:초기 조건 구성 (예: 환경 변수, 설정 값)외부 자원 수집의존성 주입에 필요한 컴포넌트 초기화 및 생성고수준 정책(UseCase, 인터랙터 등)에 제어권 위임 의존성 주입과 프레임워크 최소화의존성 주입 프레임워크는 메인 컴포넌트에서 초기 의존성들을 설정하고 주입하는 데에만 사용되어야 한다.이후에 다른 컴포넌트에서는 프레임워크에 의존하지 않고, 일반적인 방법으로..

아키텍처 경계 언제 도입해야할까?모든 컴포넌트에 아키텍처 경계가 필요한 것은 아님경계를 구현하면 비용이 든다. 그러나 무시하면 이후 더 큰 비용을 유발할 수 있다초기에는 경계가 필요 없지만, 시스템 복잡도가 증가하면 반드시 필요해진다경계는 미리 구분해두면 좋지만, 필요 이상으로 나누면 오히려 해롭다경계를 도입할 타이밍을 끊임없이 봐야한다예시: 도서관 무인 대출 시스템사용자는 초기에 무인 키오스크를 통해 도서를 대출하거나 반납함.키오스크로 본인의 대출 이력을 확인 할 수 있음또한 회원의 상태(블랙리스트, 등급, 연체 이력 등)에 따라, 도서 대출의 형태는 달라짐 1단계2단계외국인 손님도 많이 찾기 시작하면서 다국어 지원이 필요해짐.3단계키오스크 터치 입력이 불편하다는 피드백이 접수됨.4단계핸드폰으로 대출 ..

📌 아키텍처 경계를 완벽하게 만드는 것은 힘들다.완벽한 경계는 구현과 유지에 많은 비용과 노력이 필요함.쌍방향의 다형적 경계 인터페이스Input과 Output을 위한 데이터 구조독립적 컴포넌트로 컴파일 및 배포할 수 있는 구조 및 의존성 관리YAGNI(You Aren’t Gonna Need It) 원칙에 따라, 모든 경계를 미리 만들기보다는 필요할 때 경계를 도입하는 접근도 고려해볼 수 있음 → 부분적 경계📌 전략 1: 마지막 단계를 건너뛰기 (Partial Boundary)이 전략은 논리적으로는 컴포넌트를 분리하지만, 물리적으로는 분리된 배포를 생략하는 방식임.즉, 컴포넌트 내부적으로는 입력/출력 인터페이스, 데이터 구조, 책임 분리를 모두 갖추고 있음.그러나 각 계층을 다른 배포 단위로 나누지 않..

험블 객체 패턴 (Humble Object Pattern)정의테스트하기 어려운 코드와 테스트하기 쉬운 코드를 분리하여 단위 테스트 작성이 쉽도록 하는 디자인 패턴임.GUI, 네트워크, 입출력 등 테스트가 어려운 행위를 분리하여 다른 객체로 위임함.핵심 개념아키텍처 경계를 넘는 시점에는 테스트가 어려운 무언가(예: UI, 네트워크, DB)가 존재함.험블 객체 패턴은 이 경계 근처에 존재하는 테스트 어려운 부분과,테스트 가능한 부분을 분리하여 테스트 용이성을 높이기 위한 전략으로 사용할 수 있음.프레젠터와 뷰경계: 유스케이스 → 시스템 (출력)프레젠터(Presenter): 유스케이스의 출력을 뷰 모델로 변환테스트 용이 → 일반 객체뷰(View): 사용자에게 데이터를 보여주는 컴포넌트테스트 어려움 (렌더링, ..