1) 계층 기반 패키지(수평 계층형 아키텍처)정의controller → service → data처럼 유사 역할끼리 수평으로 묶는 구조임."엄격한 계층형 아키텍처"는 바로 아래 계층에만 의존함.장점빠르게, 기능이 동작하는 서비스를 개발할 수 있다.문제서로 다른 도메인도 겉모습이 크게 컨트롤러→서비스→리포지터리로 같아 보임. 도메인 정체성이 드러나지 않음.2) 기능 기반 패키지 (수직 슬라이싱)정의연관 기능/도메인 개념을 세로로 묶음. 예: orders/, payments/ 등.장점 한 패키지 안에, 관련 기능의 코드가 담겨 있음, 찾기 쉬움단점저수준 정책의 변화도 컴포넌트 전체의 빌드, 테스트, 배포에 영향을 미침3) 포트와 어댑터 (헥사고날/클린)정의내부(도메인/애플리케이션) 과 외부(UI, DB, 3..

1. 액터 & 유스케이스 분석하기단일 책임 원칙에 따라 액터(시스템의 기능 변경의 주요 원인)를 구분함한 액터를 위한 변경이 다른 액터에 영향을 주지 않도록 설계함기능 변경의 이유는 반드시 특정 액터에게 해당 기능을 제공하기 위함이어야 함여기서 ‘기능’이란 프레임워크나 DB 기술이 아니라, 비즈니스 요구사항을 의미함 2. 컴포넌트 아키텍처 설계하기독립된 배포 단위는 개발 팀과 협의하여 결정함배포 단위 설정 예시:같은 액터의 기능별로 배포뷰, 프레젠터, 인터랙터, 컨트롤러 등 동일한 역할을 수행하는 컴포넌트끼리 묶어서 배포뷰와 프레젠터를 묶어서 배포배포 단위는 상황에 따라 변경될 수 있으므로 유연한 구조로 개발함 3. 의존성 관리 체크하기컴포넌트의 의존성이 더 높은 수준의 정책을 포함하는 컴포넌트로 향하는..

데이터베이스는 세부사항이다.데이터베이스는 소프트웨어 시스템의 아키텍처적 관점에서 하위 세부사항에 불과함.아키텍처에서 중요한 것은 단순한 데이터 구조나 접근 방식이 아니라, 도메인 개념을 반영한 데이터 모델링이다. 웹은 세부사항이다.웹은 입출력 장치와 밀접한 관계를 가지며, GUI로 분류됨.업무 규칙이 UI와 뒤섞이면, 마케팅 변화나 플랫폼 전환 시 전체 시스템에서 재활용할 부분이 적어진다.아키텍처는 GUI와 같은 요소에서 업무 로직을 분리해 설계해야 함.유스케이스는 입력, 처리, 출력으로 구성된 업무 흐름이며, 이 흐름은 화면 구성과 무관하게 독립적으로 정의될 수 있음.이를 먼저 구조화해두면, 웹이든 데스크탑 앱이든 어떤 UI든 해당 흐름을 재사용할 수 있음. 프레임워크는 세부사항이다.프레임워크의 업데이..

기능 동작에만 집중한 개발의 한계임베디드 개발자의 일부는 요구된 기능이 정상 동작하는 것에만 집중하여 코드를 작성하는 경우가 있음.처음부터 특정 하드웨어에만 사용될 것이라는 전제로 개발하게 되어 모든 기능이 해당 하드웨어에 밀접하게 결합그 결과, 코드는 재사용이 어려워지고, 다른 하드웨어 환경에서는 이식이 불가능한 구조가 되어버림.타깃-하드웨어 병목현상특정 하드웨어에 종속된 개발은 개발 병목을 유발함→ 하드웨어가 도착하지 않았거나, 하드웨어에 결함이 있을 경우→ 해당 상황에 종속된 소프트웨어 개발도 지연될 수밖에 없음→ 즉, 개발의 병목은 하드웨어 상태에 의해 발생함 하드웨어가 변경되면, 코드도 함께 영향을 받음→ 일부 하드웨어 변경이 있어도 전체 기능 흐름이 깨질 수 있음→ 하드웨어에 맞춰 코드를 맞물..

테스트와 아키텍처아키텍처 관점에서 테스트는 모두 동등함.가장 바깥 원에 존재하며, 시스템 내부에 의존하지 않음.테스트의 독립성테스트는 상용 시스템과 무관하게 테스트 시스템으로 독립 배포됨.운영을 위한 것이 아니라, 개발을 지원하기 위해 존재함.테스트를 고려한 설계시스템에 결합된 테스트는 시스템 변경 시 함께 수정돼야 함.사소한 컴포넌트 변경에도 수백~수천 개 테스트가 깨짐.이 문제는 Fragile Tests Problem이라 불림. 결국, 테스트가 많을수록 시스템 수정이 어려워짐. 개발자는 코드를 바꾸는 것을 꺼리게 됨. 테스트를 고려해 설계할 것.변동성이 있는 것에 의존하지 말 것.테스트 API테스트를 쉽게 만들고 유지하려면, 테스트 전용 API가 필요함. 업무 규칙 검증에만 집중된 API로, 보안 ..