[KOSTA] 도메인 모델 기반의 서비스 설계 (DDD)

사전 지식

※ 해당 내용은 ChatGPT(80%) + 인터넷 검색(20%) 을 통해 정리 했습니다.

 

✅ 소프트웨어 개발 순서

※ 방법론과 접근 방식에 따라 다를 수 있지만, 일반적인 소프트웨어 공학에서 다음과 같이 포함한다.

1. 요구사항 분석(Requirements Analysis)
   • 목적: 시스템이 무엇을 해야하는지에 대해 고객의 요구사항을 명확히 정의
   • 활동: 요구사항을 수집하고 문서화
   • 산출물: 요구사항 명세서(Software Requirements Specification)
2. 시스템 설계(System Design)
   • 목적: 요구사항을 충족할 수 있는 시스템 구조와 설계를 정의
   • 활동: 시스템 아키텍처 설계, 데이터베이스 설계, UI/UX 설계 등을 수행
   • 산출물: 시스템 설계 문서, 아키텍처 다이어그램, 데이터 모델
3. 상세 설계(Detailed Design)
   • 목적: 시스템 설계를 세부적으로 정의하고, 구현할 각 모듈과 컴포넌트를 설계한다.
   • 활동: 클래스 다이어그램, 순서도, 상태 다이어그램 등을 작성
   • 산출물: 상세 설계문서, 모듈 설계서
4. 구현(Implementation)
   • 목적: 설계를 기반으로 실제 코드를 작성하여 소프트웨어를 개발
   • 활동: 코딩, 유닛 테스트 작성 및 수행, 코드리뷰
   • 산출물: 소스코드, 유닛 테스트 결과
5. 통합 및 테스트(Integration and Testing)
   • 목적: 개발된 묘듈을 통합하고, 전체 시스템이 정상적으로 동작하는지 테ㅡ트
   • 활동: 통합 테스트, 시스템 테스트
   • 산출물: 테스트 계획서, 테스트 시나리오, 테스트 결과 보고서
6. 배포(Deployment)
   • 목적: 개발된 소프트웨어를 실제 운영 환경에 배포한다.
   • 활동: 배포 준비, 배포 스크립트 작성, 운영 환경 설정 및 배포
   • 산출물: 배포 문서, 배포된 시스템
7. 유지보수(Maintenance)
   • 목적: 운영 중 발생하는 문제를 해결하고, 변경된 요구사항을 반영하여 시스템을 개선
   • 활동: 버그 수정, 성능 개선, 기능 추가
   • 산출물: 패치, 업데이트 릴리즈, 유지보수 기록

✅ 소프트웨어 개발 방법론

• 폭포수 모델
  • 위 개발 순서를 순차적으로 진행, 각 단계가 완료된 후 다음 단계로 넘어감.
• 애자일 모델
  • 위 단계들이 반복적이고 점진적으로 진행.
  • 스프린트나, 이터레이션 단위로 소프트웨어를 개발
  • 각 스프린트마다 요구사항 분석, 설계, 구현, 테스트, 배포가 포함.

✅  From Monolith to Microservices 

1. Monolithic v1 - 모듈화
   • 모든 기능을 한 어플리케이션에 구현
2. Monolithic v2 - Layered Arch
   • Presentation - Business - Persistence
3. Microservies - MSA
   • 독립적

 

✅  DDD와 MSA

• DDD는 소프트웨어 설계 방법론
• MSA는 아키텍처 스타일 및 개발 방법론 
• 두 방법론은 상호 보완적으로 작용할 수 있다.

 

---

도메인 주도 설계(Domain Driven Design)

※ DDD는 소프트웨어 설계 방법론이다.

 

 

Domain

It refers to the subject area or problem space that the software system is being built to address. It encompasses the real-world concepts, rules, and processes that the software is intended to model or support.

For example, in a banking application, the domain includes concepts like accounts, transactions, customers, and regulations related to banking operations.

 

소프트웨어 시스템이 해결하기 위해 구축되고 있는 주제 영역이나 문제 공간을 의미한다. 소프트웨어가 모델링 또는 지원하고자 하는 실제 개념, 규칙 및 프로세스를 포괄한다.

예를 들어, 은행 애플리케이션에서 도메인은 계정, 거래, 고객 및 은행 운영과 관련된 규정과 같은 개념을 포함합니다.

 

Driven

“Driven” implies that the design of the software system is guided or influenced by the characteristics and requirements of the domain.

In other words, the design decisions are based on a deep understanding of the domain, rather than being driven solely by technical considerations or implementation details.

 

"Driven"은 소프트웨어 시스템의 설계가 도메인의 특성과 요구사항에 의해 안내되거나 영향을 받는다는 것을 의미한다.

즉, 설계 결정은 기술적 고려 사항이나 구현 세부 사항에 의해서만 추진되는 것이 아니라 도메인에 대한 깊은 이해에 기초한다.

Design

“Design” refers to the process of creating a plan or blueprint for the software system. This includes decisions about how the system will be structured, how different components will interact, and how the system will fulfill its functional and non-functional requirements. In the context of Domain-Driven Design, the focus is on designing the software in a way that accurately reflects the structure and behavior of the domain.

 

"디자인"은 소프트웨어 시스템에 대한 계획이나 청사진을 만드는 과정을 말한다. 여기에는 시스템이 어떻게 구성될 것인지, 서로 다른 구성 요소가 어떻게 상호 작용할 것인지, 시스템이 기능적 및 비기능적 요구 사항을 어떻게 충족할 것인지에 대한 결정이 포함된다. 도메인 기반 설계의 맥락에서, 도메인의 구조와 행동을 정확하게 반영하는 방식으로 소프트웨어를 설계하는 데 초점을 맞추고 있다.

 

tactical design patterns in DDD

In Domain-Driven Design (DDD), tactical design patterns are specific strategies or techniques used to structure and organize the domain model within a software system. These patterns help developers effectively capture the complexity of the domain, while also promoting maintainability, flexibility, and scalability.

 

도메인 주도 설계(DDD)에서 전술적 설계 패턴(Tactical Design Patterns)은 소프트웨어 시스템 내에서 도메인 모델을 구조화하고 조직하는 데 사용되는 특정 전략이나 기술입니다. 이러한 패턴은 개발자가 도메인의 복잡성을 효과적으로 포착하도록 도와주며, 유지보수성, 유연성, 확장성을 촉진합니다.

 

Entities: An entity is an object with a unique identity that persists over time. For example, in a banking application, customers and accounts would be entities.

 

엔티티는 시간에 걸쳐 지속되는 고유한 정체성을 가진 객체입니다. 예를 들어, 은행 애플리케이션에서는 고객과 계좌가 엔티티에 해당합니다.

• An entity has a unique identifier in the system, which can be used to look up or retrieve the entity. That doesn't mean the identifier is always exposed directly to users. It could be a GUID or a primary key in a database.
  (엔티티는 시스템 내에서 고유 식별자를 가지며, 이를 통해 엔티티를 조회하거나 검색할 수 있습니다. 이 식별자가 항상 사용자에게 직접 노출되는 것은 아닙니다. 이는 GUID 또는 데이터베이스의 기본 키일 수 있습니다.)
• An identity may span multiple bounded contexts, and may endure beyond the lifetime of the application. For example, bank account numbers or government-issued IDs are not tied to the lifetime of a particular application.
  (정체성은 여러 바운디드 컨텍스트에 걸쳐 있을 수 있으며, 애플리케이션의 수명보다 더 오래 지속될 수 있습니다. 예를 들어, 은행 계좌 번호나 정부 발급 신분증은 특정 애플리케이션의 수명과 관련이 없습니다.)
• The attributes of an entity may change over time. For example, a person's name or address might change, but they are still the same person.
  (엔티티의 속성은 시간이 지나면서 변경될 수 있습니다. 예를 들어, 사람의 이름이나 주소가 변경될 수 있지만, 여전히 동일한 사람으로 간주됩니다.)
• An entity can hold references to other entities.
  (엔티티는 다른 엔티티에 대한 참조를 가질 수 있습니다.)

Value objects:A value object has no identity. It is defined only by the values of its attributes. Value objects are also immutable. To update a value object, you always create a new instance to replace the old one. Value objects can have methods that encapsulate domain logic, but those methods should have no side-effects on the object's state. Typical examples of value objects include colors, dates and times, and currency values.

 

값 객체(Value Object)는 정체성이 없습니다. 값 객체는 오직 그 속성의 값들에 의해서만 정의됩니다. 값 객체는 또한 불변(immutable)입니다. 값을 업데이트하려면 항상 새로운 인스턴스를 만들어 기존의 값을 대체해야 합니다. 값 객체는 도메인 로직을 캡슐화하는 메서드를 가질 수 있지만, 이러한 메서드는 객체의 상태에 부작용을 주어서는 안 됩니다. 값 객체의 일반적인 예로는 색상, 날짜와 시간, 화폐 가치 등이 있습니다.

 

For example, a Money value object might represent a specific amount of currency, encapsulating properties like currency type and amount.

예를 들어, Money 값 객체는 특정 금액의 화폐를 나타낼 수 있으며, 화폐 종류와 금액 같은 속성을 캡슐화할 수 있습니다.

 

 

Aggregates

• An aggregate is a cluster of domain objects that are treated as a single unit for the purpose of data consistency and transactional integrity.
  (데이터 일관성과 트랜잭션 무결성을 목적으로 하나의 단위로 취급되는 도메인 객체들의 클러스터입니다.)
• Aggregates consist of one or more entities and value objects, with one entity designated as the aggregate root.
  (애그리게이트는 하나 이상의 엔티티와 값 객체로 구성되며, 하나의 엔티티가 애그리게이트 루트로 지정됩니다.)
• The aggregate root serves as the entry point for accessing and modifying the aggregate’s internal state.
  (애그리게이트 루트는 애그리게이트의 내부 상태에 접근하고 수정하는 진입점 역할을 합니다.)
• Aggregates enforce consistency boundaries within the domain model, ensuring that changes to related objects are made atomically.
  (애그리게이트는 도메인 모델 내에서 일관성 경계를 강제하여 관련 객체들의 변경이 원자적으로 이루어지도록 보장합니다.)

 

모델 주도 설계(MDD)

구성체(aggregate)

• 데이터 변경 단위로 다뤄지는 연관 객체의 집합
• 구성체는 루트와 경계가 있따.

팩토리(factory)

• 객체 생성 또는 전체 구성체가 복잡해지거나 너무 많은 내부 구조를 밝혀야할 경우 팩토리로 감싼다.

 

MDD와 DDD의 비교

측면	모델 주도 개발 (MDD)	도메인 주도 설계 (DDD)
중심 개념	모델 (모델 기반 코드 생성)	도메인 (비즈니스 도메인 이해 및 설계)
주요 도구	UML, 코드 생성기, 모델 변환 도구	유비쿼터스 언어, 바운디드 컨텍스트, 도메인 객체
목표	개발 효율성 및 자동화	도메인 이해 및 복잡성 관리
초점	모델에서 코드로 변환	도메인 모델 설계 및 구현
장점	생산성 향상, 일관성, 문서화	도메인 이해, 유연성, 고품질 소프트웨어
단점	초기 학습 비용, 제한된 유연성	시간 소모, 복잡성

 

 

참고사이트

• https://www.geeksforgeeks.org/domain-driven-design-ddd/
• https://incheol-jung.gitbook.io/docs/q-and-a/architecture/ddd
• https://medium.com/@puneet.vyas/how-to-migrate-from-monolithic-to-microservices-part-i-bd0645a7c529
• https://learn.microsoft.com/en-us/azure/architecture/microservices/model/domain-analysis