아키텍처 패턴 선택

상태

승인

후보군

방안	설명
Hexagonal + Rich Domain Model	presentation → application → domain ← infrastructure 레이어. 판정·전이는 Entity에 캡슐화
레이어드 아키텍처 + Anemic Model	Service 클래스에 로직 집중, Entity는 getter/setter만 보유

결정

presentation → application → domain ← infrastructure 레이어 구조를 채택한다. 도달 판정·상태 전이는 PriceAlert Entity에 캡슐화하고, UseCase는 DomainService만 호출한다. Gateway/Repository interface는 domain에 정의하며 OutputPort 패턴은 사용하지 않는다.

결정 이유

• 도달 판정·상태 전이 등 비즈니스 규칙이 흩어지면 유지보수가 어렵다.
• Rich Domain Model로 Entity에 캡슐화하면 레이어별 단위 테스트가 단순해진다.
• OutputPort 미사용으로 불필요한 보일러플레이트를 줄인다.

검토 대안

방안	기각 이유
레이어드 아키텍처 + Anemic Model	비즈니스 규칙이 Service에 집중되어 테스트·유지보수 어려움

트레이드 오프

• 득: 레이어별 테스트 분리 용이, 비즈니스 규칙 Entity 캡슐화, 의존 방향 명확
• 실: 초기 클래스 수 증가로 보일러플레이트 상대적 증가