24일차. IT 개념 정리

---

스트링부트에서 DDD철학에 기반하여 개발하는것과 EDD에 기반하여 개발하는 것을 비교해줘

 

 

Spring Boot 환경에서 DDD(Domain-Driven Design, 도메인 주도 설계) 와 EDD(Event-Driven Design, 이벤트 주도 설계) 는 모두 대규모 시스템 설계에 자주 사용되는 철학입니다.
하지만 두 방식은 관점, 초점, 아키텍처 구성 방식이 다릅니다.
아래에 비교를 체계적으로 정리해드릴게요.

---

🧩 개요 비교

구분DDD (도메인 주도 설계)EDD (이벤트 주도 설계)

핵심 개념	도메인(비즈니스 로직)을 중심으로 설계	이벤트(event)를 중심으로 시스템 간 통신 설계
주요 목적	복잡한 비즈니스 로직을 명확히 모델링	시스템 간 비동기적 연동과 확장성 확보
설계 초점	도메인 모델, 애그리게잇, 리포지토리, 서비스	이벤트 발행(Publish)과 구독(Subscribe) 흐름
주요 구성요소	Entity, Value Object, Domain Service, Aggregate Root	Event, Event Producer, Event Consumer, Message Broker
통신 방식	주로 동기 (메서드 호출, REST 등)	비동기 (Kafka, RabbitMQ, Event Bus 등)
적합한 상황	복잡한 비즈니스 규칙 중심의 도메인	마이크로서비스 간 비동기 통신이 필요한 시스템

---

⚙️ Spring Boot 기반 구현 관점 비교

🟢 DDD 기반 개발 방식

1. 구조 예시

 

2. 특징

• 도메인 중심으로 패키지를 구성하여, 비즈니스 규칙을 코드에 명확히 반영합니다.
• 예를 들어 Order 도메인의 상태 변화(OrderCreated, OrderPaid, OrderShipped)를 엔티티 내부에서 관리합니다.
• 유지보수가 쉽고, 도메인 전문가(기획자)와의 협업이 용이합니다.

3. 단점

• 초기 설계가 복잡하고, 도메인 모델링에 많은 시간 투자 필요
• 마이크로서비스로 분리하기엔 경계 설정이 모호할 수 있음

---

🟡 EDD 기반 개발 방식

1. 구조 예시

 

2. 특징

• 비즈니스 로직이 이벤트 단위로 분리되어, 서비스 간 결합도가 낮아집니다.
• 예: 주문 생성 → OrderCreatedEvent 발행 → 재고 서비스에서 해당 이벤트 소비
• Spring Boot에서는 Spring Cloud Stream, Kafka, RabbitMQ 등을 활용합니다.

3. 단점

• 이벤트 흐름을 추적하기 어려움 (디버깅, 트랜잭션 관리 복잡)
• 단순한 시스템에서는 오히려 과도한 설계가 될 수 있음

---

🧠 결합 전략 (DDD + EDD)

사실 최근에는 DDD와 EDD를 결합하는 설계가 많이 사용됩니다.
DDD를 통해 도메인 모델을 명확히 정의하고, 그 안에서 발생하는 도메인 이벤트를 EDD로 처리하는 방식입니다.

예시:

 

// DDD 도메인 엔티티 public class Order { private OrderId id; private Money totalPrice; private OrderStatus status; public OrderCreatedEvent create() { this.status = OrderStatus.CREATED; return new OrderCreatedEvent(this.id); } }

 

// EDD 이벤트 핸들러 @Component public class OrderEventHandler { @EventListener public void handle(OrderCreatedEvent event) { inventoryService.decreaseStock(event.getOrderId()); } }

이렇게 하면

• DDD의 도메인 명확성
• EDD의 비동기 확장성
  을 동시에 확보할 수 있습니다.

---

✅ 정리 요약

구분DDDEDD

초점	도메인 로직과 모델링	시스템 간 이벤트 흐름
장점	복잡한 비즈니스 로직 표현에 강함	서비스 간 확장성과 느슨한 결합
단점	초기 설계 복잡, 확장성 한계	추적 어려움, 트랜잭션 복잡
권장 조합	DDD 기반 + 도메인 이벤트를 EDD로 처리

---

@Bean @component @controller @ service @repository @ entity 중에서 성격이 다른 것이 있으면 분리해주고, 이거들이 스프링의 bean 객체와 어떤 관계가 있는지 알려줘

 

 

스프링(Spring)에서 @Bean, @Component, @Controller, @Service, @Repository, @Entity는 모두 애플리케이션 구성 요소를 정의하거나 등록하는 데 사용되는 어노테이션이지만, 그 역할과 동작 방식이 조금씩 다릅니다.
특히, 이 중에는 Spring Bean과 무관하거나 간접적으로만 관련된 것도 있습니다.
아래에 정리해드리겠습니다.

---

🧩 먼저 분류부터

분류어노테이션역할스프링 Bean 등록 여부

✅ 스프링 빈(Bean) 관련 그룹	@Component, @Controller, @Service, @Repository, @Bean	애플리케이션 실행 시 Spring IoC 컨테이너에 등록되는 객체를 정의	Bean으로 등록됨
🚫 성격이 다른 그룹	@Entity	JPA에서 데이터베이스 테이블과 매핑되는 도메인 객체	Bean으로 등록되지 않음

---

🟢 1. 스프링 빈 관련 어노테이션

이들은 모두 스프링 컨테이너가 관리하는 객체, 즉 Spring Bean을 등록하기 위한 어노테이션입니다.

🔸 @Component

• 스프링이 관리해야 할 기본적인 클래스에 붙이는 어노테이션
• 가장 일반적이고 상위 개념
• 예시:
•  
  @Component
• public class MailSender { ... }

🔸 @Controller

• @Component의 특수화 어노테이션
• 웹 요청을 처리하는 MVC 컨트롤러로 인식
• 스프링이 DispatcherServlet을 통해 요청을 매핑함
• 예시:
•  
  @Controller
• public class UserController { ... }

🔸 @Service

• @Component의 특수화
• 비즈니스 로직을 담당하는 계층을 명시적으로 표현
• 트랜잭션이나 로깅 등 AOP(관점 지향 프로그래밍) 적용 시 인식에 유리
• 예시:
•  
  @Service
• public class OrderService { ... }

🔸 @Repository

• @Component의 특수화
• 데이터 접근 계층(DAO) 에서 사용
• 스프링이 JPA 예외를 Spring DataAccessException으로 변환할 때 자동 인식
• 예시:
•  
  @Repository
• public class OrderRepository { ... }

🔸 @Bean

• 직접 Bean을 생성해서 등록할 때 사용
• 메서드 단위에서 Bean을 반환하며, @Configuration 클래스 안에 선언됨
• 즉, 개발자가 수동으로 Bean을 등록하는 방식
• 예시:
•  
  @Configuration
• public class AppConfig { @Bean public MailSender mailSender() { return new MailSender(); } }

📌 정리하자면

• @Component, @Controller, @Service, @Repository → 자동 스캔(Auto-detection) 으로 Bean 등록
• @Bean → 수동 등록(Explicit registration) 방식

---

🔴 2. 성격이 다른 어노테이션: @Entity

@Entity

• JPA(Java Persistence API)에서 DB 테이블과 매핑되는 클래스임을 표시
• 스프링 빈과는 별개의 개념입니다.
• @Entity 객체는 스프링 IoC 컨테이너가 아닌 JPA EntityManager에 의해 관리됩니다.
• 예시:
•  
  @Entity
• public class User { @Id private Long id; private String name; }

즉,
👉 @Entity는 Spring Bean이 아니라, 데이터베이스 레벨의 엔티티 객체입니다.

---

🧠 스프링 Bean과의 관계 요약

어노테이션Bean 등록 방식관리 주체주요 역할

@Component	자동	Spring IoC	일반 컴포넌트
@Controller	자동	Spring IoC	웹 요청 처리
@Service	자동	Spring IoC	비즈니스 로직 처리
@Repository	자동	Spring IoC	데이터 접근 계층
@Bean	수동	Spring IoC	명시적 Bean 등록
@Entity	❌ Bean 아님	JPA EntityManager	DB 매핑 객체

---

✅ 결론 요약

• @Component, @Controller, @Service, @Repository, @Bean → Spring Bean 등록용
• @Entity → JPA 전용, Spring Bean 아님
• 스프링에서 Bean으로 관리된다는 것은 IoC 컨테이너가 객체의 생성, 초기화, 주입, 소멸을 관리한다는 것을 의미합니다.

 

---