따맵 백엔드를 구현하고 코드를 통합하면서 클로드가 헥사고날과 DDD 방향으로
코드를 통합한 잇슈 .. 패키지 구조를 하나도 못알아보겠는 까막눈 잇슈 ..

헥사고날 아키텍처와 DDD

헥사고날 아키텍처와 DDD는 둘 다 도메인(비지니스 로직)을 중심에 둔다는 공통점이 있지만,
헥사고날 아키텍처는 "시스템을 어떻게 계층화하고 의존성을 배치할까?"에 초점
DDD는 "도메인을 어떻게 모델링할까?"에 초점

헥사고날 아키텍처

Hexagonal Architecture

🍀 헥사고날 아키텍처의 필요성

기존에 주로 개발하던 계층형 구조는 단순하고 직관적이다.

• Controller : 외부 요청을 받는 역할
• Service : 비지니스 로직
• Repository : DB 접근

하지만 계층형 구조의 문제점은 의존성 방향에 있다.
Controller → Service → Repository 순서로
아래로 내려가야 하고, Service 레이어는 DB같은 외부 인프라에 강하게 의존하게 된다.
따라서 비지니스 로직이 DB나 프레임워크에 종속되는 상황이 발생할 수 있다 ! !

🍀 헥사고날 아키텍처의 핵심 아이디어

• 비지니스 로직(=도메인)을 중심에 둔다.
• DB, UI, 외부 API 등은 바깥쪽에 둔다.
• 도메인이 바깥쪽 인프라에 직접 의존하지 않는다.

따라서 어떤 프레임워크나 DB를 쓰더라도 비지니스 로직은 흔들리지 않는게 핵심이다.

• [규칙서] Domain : 순수한 핵심 규칙(비지니스 로직), DB/웹/프레임워크를 모름
• [지시자] Application : 유스케이스(Service 역할), Domain을 이용해 시나리오 실행
• [계약서] Port : Application이 외부에 기대는 인터페이스(Ex. UserRepository)
• [실행자] Adapter : Port를 구현한 구체체(Ex. JPA 기반 JpaUserRepository)

즉, 헥사고날 아키텍처는 비지니스 로직을 외부 기술에서 독립시키는 구조

도메인 주도 설계

DDD, Domain-Driven Design

🍀 DDD의 필요성

보통 개발을 하면 발생하는 문제점:

• 코드가 기능 단위로만 작성 → 시간이 지나면 스파게티 코드
• 비지니스 규칙이 흩어져서 어디서 처리되는지 불명확
• 요구사항 변경 시 수정해야 할 코드가 여러 군데

DDD는 도메인(비지니스 문제)를 중심에 두고, 이를 코드에 직접 반영하려는 접근
(뭔 소릴까 ..?)

🍀 DDD의 핵심 아이디어

• 도메인에 집중한다.
  • 도메인 = 해결하려는 문제 영역
  • Ex. 따맵 : 자전거, 대여소, 사용자 / 은행 시스템 : 계좌, 송금, 대출
• 유비쿼터스 언어
  • 개발자, 기획자, 현업 담당자 모두 같은 용어를 사용
  • '결제 승인'이라는 말을 코드에도 그대로 approvePayment()로 반영

🍀 DDD의 기본 빌딩 블록

DDD에서는 코드를 도메인 개념에 맞게 나눈다.

(1) Entity (엔티티)

• 고유한 ID로 구별되는 객체
• 값이 변해도 동일성을 유지
• Ex. User(id=1, name="의연") → 이름 바뀌어도 id=1이면 같은 User

(2) Value Object (값 객체)

• 속성 값 자체로만 의미가 있는 객체 (ID 없음❌)
• 불변(immutable)으로 다루는 게 일반적
• Ex. Money(1000, "KRW"), Email("velog@gmail.com")

(3) Aggregate

• Entity + VO 묶음 → 하나의 비즈니스 단위
• 항상 일관성을 유지해야 함
• 대표 엔티티 = Aggregate Root
• Ex. Order (root) → OrderItem(entity), Money(VO)

(4) Repository

• Aggregate 저장/조회 담당
• DB 접근을 추상화 (interface)
• Ex. OrderRepository.save(order)

(5) Domain Service

• 특정 Entity 하나에 속하지 않는 비즈니스 규칙을 담는 곳
• Ex. 환율 계산, 결제 승인

어렵땅 ...