의존성소프트웨어는 중심(엔티티)으로 갈수록 고수준 정책을 나타냄의존성은 반드시 안쪽(고수준)을 향해야 하며, 외부 원의 이름을 내부에서 직접 참조해서는 안 됨내부에서 외부를 사용할 땐 인터페이스를 통해 간접 의존해야 함엔티티 (Entity)핵심 업무 규칙을 담당하는 계층기업 전반에 걸쳐 재사용 가능한 고수준 정책외부 변경(유스케이스, UI, DB 등)으로 인해 변경되면 안 됨유스케이스 (Use Case)애플리케이션에 특화된 업무 규칙을 포함엔티티를 활용해 유스케이스 목적을 달성시스템의 모든 유스케이스를 이 계층이 구현함UI나 DB 변경에는 영향받지 않지만, 비즈니스 흐름 변경에는 수정되어야 함인터페이스 어댑터 (Interface Adapter)내부와 외부 간의 데이터 변환을 담당하는 계층유스케이스와 외부..

소프트웨어 어플리케이션의 아키텍처는 유스케이스가 중심이 되어야 한다. 프레임워크(Spring, React 등)는 껍데기에 불과하다. 아키텍처의 중심이 되어서는 안 된다.아키텍처의 목적좋은 아키텍처는 프레임워크, 데이터베이스, 웹 서버 같은 외부 요소에 대한 결정을 늦출 수 있게 한다. 프레임워크는 언제든 교체 가능한 열린 선택지여야 한다.이런 아키텍처는 프로젝트 후반까지도 Rails, Spring, Hibernate, MySQL 같은 도구에 대한 결정을 유보할 수 있으며, 필요할 경우 쉽게 변경 가능해야 한다.즉, 유스케이스에 집중하고 지엽적인 관심사(입출력, 저장 등)는 분리해야 한다.웹은 아키텍처의 일부일까?웹은 단지 사용자와의 입출력을 처리하는 계층일 뿐이다.결국, 외부 요소이다.프레임워크는 도구일..

용어 정리업무 규칙: 수익을 얻거나 비용을 줄이기 위한 절차나 규칙핵심 업무 규칙: 컴퓨터로 구현되었는지 여부와 상관없이 본질적인 업무 절차핵심 업무 데이터: 핵심 업무 규칙이 다루는 상태값들엔티티 (Entity)정의시스템 내부의 비즈니스 개념을 대표하는 객체핵심 업무 데이터와 규칙을 함께 가지며 외부와 완전히 분리됨 특징순수하게 업무에 대한 규칙만 포함어떤 시스템에서도 동일하게 업무를 수행할 수 있어야 함개발 언어, 데이터 저장 방식, 프레임워크, 컴퓨터 배치 방식과도 무관그 어떤 시스템의 고려사항들이 엔티티에 영향을 주면 안됨. 절대 독립적 예시 – 주문 수수료 계산class Order { // 엔티티 constructor( // 핵심 업무 데이터 private readonly totalAmo..

소프트웨어 시스템 내부에서의 정책'정책'이란 입력을 출력으로 바꾸는 로직을 의미함소프트웨어 시스템은 입력을 출력으로 바꾸는 '정책'을 코드로 구현한 것 정책과 의존성 방향아키텍처는 정책이 변경되는 이유와 시점을 기준으로 컴포넌트를 나눠야 함동일한 이유, 동일한 시점에 변경되는 정책은 동일한 수준의 컴포넌트에 속해야 함서로 다른 이유, 다른 시점에 변경되는 정책은 반드시 분리된 컴포넌트로 구성해야 함 의존성 그래프 구조시스템은 정점(node)과 간선(edge)으로 이루어진 방향 비순환 그래프(DAG)로 표현됨정점은 동일한 수준의 컴포넌트, 간선은 컴포넌트 간의 의존성을 의미함의존성 방향은 낮은 수준에서 높은 수준으로만 흐르도록 구성해야 함. 수준'수준(level)'이란 입력과 출력까지의 거리를 의미함..

좋은 소프트웨어 아키텍처란, 경계를 설정하는 기술이다.경계는 요소(컴포넌트, 객체)를 분리하고, 불필요한 조기 결정을 늦춤으로써 핵심 업무 로직을 오염시키지 않도록 하는 데 목적이 있다. 이른 결정을 피해야 하는 이유는, 그러한 결정이 시스템의 유지 효율성을 급격히 떨어뜨리는 결합도를 야기하기 때문이다. 특히 업무 요구사항과 무관한 결정(예: 프레임워크, DB, DI 프레임, 라이브러리 등)은 가능한 한 늦게 내리는 것이 바람직하다. 좋은 아키텍처는 이러한 조기 결정을 유예할 수 있게 설계되며, 설령 나중에 결정하더라도 시스템 전체에 영향을 주지 않도록 한다.📌 사례 1: 너무 이른 결정이 만든 과도한 복잡성사내에서 사용하는 단순한 휴가 신청 시스템을 만들기로 했다. 요구사항은 간단했다. 직원이 휴가를..