개발자로서 우리는 종종 도메인 모델과 일치하고 비즈니스 요구 사항을 충족하는 소프트웨어 시스템을 구축하기를 원합니다. 그것이 DDD가 들어오는 곳입니다.

DDD(Domain-Driven Design)는 도메인 모델을 구현과 일치시키는 데 중점을 두는 소프트웨어 시스템을 개발하기 위한 방법론입니다. 문제 영역에 집중하고 관련 개념 및 관계에 대한 이해를 공유함으로써 개발자는 이해 관계자의 요구 사항을 더 잘 반영하고 변화하는 비즈니스 요구 사항에 더 잘 적응할 수 있는 소프트웨어를 만들 수 있습니다.

DDD를 지원하기 위해 개발자는 도메인 모델링, 데이터 매핑 및 테스트와 같은 작업에 도움이 되는 다양한 도구와 기술을 사용할 수 있습니다. 이 기사에서는 DDD를 지원하는 데 사용할 수 있는 최고의 도구와 프레임워크 중 일부를 살펴보겠습니다. 이벤트 소싱 및 CQRS에서 도메인 모델링 도구 및 ORM 프레임워크에 이르기까지 다양한 도구를 다루고 주요 이점과 사용 사례를 강조합니다. 따라서 DDD를 처음 사용하든 숙련된 실무자이든 도메인 기반 소프트웨어 시스템을 구축하기 위한 최고의 도구를 알아보십시오.

도메인 모델은 무엇이며 어떻게 사용할 수 있습니까?

먼저 구매하세요. DD를 처음 사용하는 경우 방에 있는 분홍 코끼리를 빠르게 해결해 보겠습니다. "도메인 모델"이란 무엇입니까?

도메인 모델은 DDD(Domain-Driven Design)의 중심 개념이며 소프트웨어 시스템의 핵심을 나타냅니다. 이것은 소프트웨어 시스템이 다루어야 하는 실제 도메인의 개념적 모델이며 데이터의 구조와 시스템의 동작을 정의합니다. 도메인 모델은 비즈니스 전문가, 개발자 및 사용자를 포함한 모든 이해 관계자가 문제 도메인에 대해 공유하는 이해입니다.

이 모델은 다음으로 구성됩니다.

• 수명 주기가 있는 고유한 ID를 가진 객체인 엔터티.
• 트랜잭션 일관성 경계를 형성하는 관련 개체의 클러스터인 집계입니다.
• 값 개체는 고유한 ID가 없고 해당 속성으로 정의되는 개체입니다.
• 도메인 서비스는 단일 엔터티 또는 값 개체에 고유하지 않은 작업 또는 알고리즘입니다.

예를 생각해보자

저는 항상 복잡한 개념을 이해하기 위해 실용적인 예를 사용하는 것을 좋아합니다. 따라서 우리가 전자 상거래 플랫폼을 구축하고 있고 요구 사항 중 하나가 사용자가 제품을 주문할 수 있도록 허용하는 것이라고 가정해 보겠습니다.

도메인 기반 설계에서는 문제 도메인의 관련 개념과 관계를 나타내는 도메인 모델을 만드는 것으로 시작합니다.

이 도메인의 핵심 엔터티 중 하나는 사용자가 주문한 개별 주문을 나타내는 주문 엔터티입니다. 주문 엔터티에는 OrderID , CustomerID , 주문 제품 목록 , 총 가격 및 상태 (예: 보류, 이행, 취소)와 같은 속성이 있습니다.

이 도메인의 다른 엔터티는 구매할 수 있는 제품을 나타내는 제품 엔터티일 수 있습니다. Product 엔터티에는 ProductID , 이름 , 설명 , 이미지 , 가격 및 범주 목록 과 같은 속성이 있을 수 있습니다 .

집계는 트랜잭션 일관성 경계를 형성하는 관련 개체의 클러스터이므로 제품 엔터티 및 고객 엔터티와 같은 관련 엔터티와 함께 ​​주문 엔터티를 포함하는 주문 집계를 만들 수 있습니다. 이렇게 하면 이러한 엔터티에 대한 모든 변경 사항이 트랜잭션적으로 일관된 방식으로 수행됩니다.

고유한 ID는 없지만 해당 속성으로 정의되는 배송 주소 및 청구 주소와 같은 개념을 나타내는 값 개체를 만들 수도 있습니다.

마지막으로 배송비를 계산하고 적절한 배송 정보로 주문 엔터티를 업데이트하는 ShippingService와 같은 도메인 서비스를 만들 수 있습니다.

전반적으로 이 도메인 모델은 문제 도메인의 주요 개념과 관계를 이해하는 데 도움이 되며 전자 상거래 플랫폼을 구현하기 위한 기반을 제공합니다. 구현을 도메인 모델에 맞추면 보다 유연하고 유지 관리가 가능하며 변화하는 비즈니스 요구 사항에 대응하는 시스템을 만들 수 있습니다.

이제 이를 수행하는 데 도움이 될 수 있는 몇 가지 도구를 살펴보겠습니다.

이벤트 소싱 - DDD의 성배

이벤트 소싱은 집계, 엔터티 및 값 개체와 같은 DDD 개념을 구현하는 데 사용되는 기술입니다. 이벤트 소싱을 사용하면 시스템의 현재 상태를 저장하는 대신 시스템에 대한 모든 변경 사항을 일련의 이벤트로 저장합니다. 그렇게 함으로써 우리는 어느 시점에서나 시스템 상태를 재구성할 수 있으며 이는 매우 강력합니다. 소프트웨어를 위한 타임머신이 있는 것과 같습니다!

전자 상거래 플랫폼 예제를 계속 살펴보겠습니다.

시간 경과에 따라 주문 엔터티의 변경 사항을 추적하려고 한다고 가정해 보겠습니다. 이벤트 소싱을 사용하면 주문 엔터티를 직접 업데이트하는 대신 주문에 대한 상태 변경을 나타내는 일련의 이벤트를 만듭니다. 각 이벤트는 주문 엔터티의 상태에 대한 개별 변경을 나타내며 이벤트 로그에 저장됩니다.

예를 들어 사용자가 제품을 주문한다고 가정해 보겠습니다. 새 주문 세부 정보로 Order 엔터티를 직접 업데이트하는 대신 OrderID, CustomerID, 주문한 제품 목록 및 총 가격을 포함하는 OrderPlaced 이벤트를 만듭니다. 그런 다음 이 이벤트를 이벤트 로그에 추가합니다.

나중에 사용자가 제품을 추가하거나 제거하여 주문을 업데이트하면 OrderID 및 업데이트된 제품 목록을 포함하는 OrderUpdated 이벤트를 생성하고 이벤트 로그에 추가합니다. 주문이 취소되면 OrderID와 취소 이유가 포함된 OrderCanceled 이벤트를 생성하고 이벤트 로그에 추가합니다.

이벤트 소싱을 사용하면 이벤트 로그에서 이벤트를 재생하여 언제든지 주문 엔터티의 상태를 다시 만들 수 있습니다. 또한 이벤트 로그를 사용하여 주문 엔터티의 변경 사항을 감사하고 주문 내역을 보여주는 보고서를 만들 수 있습니다.

이벤트 소싱을 사용하여 이러한 객체에 대한 상태 변경을 캡처함으로써 소프트웨어 구현이 도메인 모델과 일치하도록 유지할 수 있습니다.

예를 들어 주문이 실제로 하나 이상의 OrderLine 엔터티와 ShippingAddress 값 개체로 구성된 집계라고 가정해 보겠습니다. 이벤트 소싱을 사용하여 주문 집계에 대한 각 상태 변경을 OrderPlaced, OrderUpdated 및 OrderCanceled와 같은 일련의 이벤트로 캡처할 수 있습니다. 그런 다음 이러한 이벤트를 사용하여 언제든지 주문 집계 상태를 다시 생성하여 소프트웨어 구현이 도메인 모델을 정확하게 반영하도록 할 수 있습니다.

Bit 를 사용하면 이벤트 저장소, 이벤트 핸들러 및 기타 관련 구성 요소를 포함하여 이벤트 소싱 구현을 캡슐화하는 구성 요소를 생성할 수 있습니다. 그런 다음 이 비트를 다른 팀과 공유하여 자신의 프로젝트에서 쉽게 재사용할 수 있습니다. 이를 위해 Bit를 사용하면 다양한 프로젝트와 팀에서 구현이 일관되도록 할 수 있습니다. 이것은 여러 개발 팀이 서로 다른 프로젝트에 참여하는 대규모 조직에서 특히 유용할 수 있습니다.

CQRS — 하나의 크기가 모든 것에 맞지 않을 때

CQRS(Command Query Responsibility Segregation)는 시스템에서 읽기 및 쓰기 작업을 분리하는 데 사용되는 패턴입니다. 기존 아키텍처에는 읽기와 쓰기를 모두 처리하는 단일 모델이 있어 성능 문제와 확장성 문제가 발생할 수 있습니다. CQRS는 읽기 및 쓰기 모델을 분리하여 각 모델을 독립적으로 최적화할 수 있도록 하여 이 문제를 해결합니다.

CQRS를 지원하기 위해 사용할 수 있는 몇 가지 프레임워크가 있습니다. 이러한 프레임워크 중 하나는 NestJS입니다. NestJS는 내장된 이벤트 버스를 사용하여 CQRS를 구현하므로 애플리케이션의 여러 부분에서 이벤트를 게시하고 구독할 수 있습니다. 이렇게 하면 응용 프로그램의 데이터베이스에 쓰는 명령 처리기와 데이터베이스에서 데이터를 검색하여 클라이언트에 반환하는 쿼리 처리기를 쉽게 구현할 수 있습니다.

이 두 가지 책임을 분리하면 애플리케이션의 성능이 향상되고 테스트하기 쉽고 변경에 대한 탄력성이 향상됩니다.

Bit 와 함께 NestJS를 사용하면 DDD 애플리케이션 개발 능력을 더욱 향상시킬 수 있습니다. Bit는 여러 프로젝트에서 코드 구성 요소를 공유하고 재사용할 수 있는 방법을 제공하여( 자세한 내용은 이 문서 참조 ) 팀이 보다 효과적으로 협업하고 중복 작업을 피할 수 있도록 합니다. 명령 및 쿼리 처리기와 같은 NestJS 구성 요소의 공유 라이브러리를 생성하면 애플리케이션 포트폴리오에서 작성하고 유지 관리해야 하는 코드의 양을 줄일 수 있습니다. 또한 Bit를 사용하면 시간이 지남에 따라 구성 요소에 대한 버전을 지정하고 변경 사항을 추적할 수 있으므로 종속성을 보다 쉽게 ​​관리하고 애플리케이션 간의 호환성을 보장할 수 있습니다.

도메인 모델링 도구 — 도메인 모델 시각화

아, 도메인 모델링 도구. DDD(Domain-Driven Design)에 관심이 있다면 아마 익숙할 것입니다. 그렇지 않은 경우 걱정하지 마십시오. 속도를 높일 수 있도록 도와 드리겠습니다.

그렇다면 도메인 모델링 도구는 무엇입니까? 간단히 말해서 개발자가 소프트웨어 시스템의 도메인 모델을 만들고 시각화하는 데 도움이 되는 소프트웨어 응용 프로그램입니다. 도메인 모델은 소프트웨어 시스템이 모델링하도록 설계된 실제 개념 및 관계를 나타냅니다. 이는 DDD의 필수 부분으로, 모든 이해 관계자 간에 도메인 모델에 대한 명확하고 간결하며 공유된 이해의 중요성을 강조합니다.

소프트웨어 시스템에 대한 도메인 모델을 만들고 시각화하는 데 도움이 되는 다양한 도메인 모델링 도구를 사용할 수 있습니다. 이러한 도구는 도메인 모델이 정확하고 잘 이해되었는지 확인하기 위해 도메인 전문가 및 다른 팀 구성원과 작업할 때 특히 유용할 수 있습니다.

이러한 도구의 한 예는 간단한 구문을 사용하여 클래스 다이어그램, 시퀀스 다이어그램, 사용 사례 다이어그램 등을 포함하여 UML 다이어그램을 만들 수 있는 텍스트 기반 다이어그램 작성 도구인 PlantUML입니다 . PlantUML은 오픈 소스이며 PNG, SVG 및 PDF를 포함한 여러 출력 형식을 지원합니다. 확장 또는 플러그인을 통해 Visual Studio Code를 비롯한 다양한 편집기 및 IDE와 통합할 수 있습니다.

인기 있는 또 다른 도구는 끌어서 놓기 인터페이스를 사용하여 순서도, UML 다이어그램, ER 다이어그램 등 다양한 유형의 다이어그램을 만들 수 있는 웹 기반 다이어그램 작성 도구인 Lucidchart입니다 . Lucidchart는 다양한 템플릿과 도형을 제공하여 전문가 수준의 다이어그램을 쉽고 빠르게 만들 수 있습니다.

또한 IntelliJ IDEA와 같은 일부 코드 편집기 및 IDE는 복잡한 도메인 모델이 있는 소프트웨어 시스템에서 작업할 때 유용할 수 있는 UML 다이어그램 및 기타 시각적 모델링 도구에 대한 기본 지원을 제공합니다.

전반적으로 도메인 모델링 도구는 복잡한 도메인 모델이 포함된 소프트웨어 시스템에서 작업할 때 귀중한 자산이 될 수 있습니다. 도메인 모델을 만들고 시각화하고 다른 팀 구성원과 효과적으로 전달하여 비즈니스 요구 사항에 맞는 소프트웨어 시스템을 보다 쉽게 ​​구축할 수 있도록 도와줍니다.

ORM(Object-Relational Mapping) 프레임워크

DDD 구현의 주요 과제 중 하나는 개체를 관계형 데이터베이스에 매핑하는 것입니다. 이것은 ORM 프레임워크가 유용한 곳입니다. ORM 프레임워크는 개체를 관계형 데이터베이스의 테이블에 매핑하는 방법을 제공합니다. 이를 통해 프레임워크가 데이터베이스 상호 작용을 처리하는 동안 코드의 개체로 작업할 수 있습니다.

모든 언어에 대한 공통 ORM 프레임워크가 많이 있습니다. JavaScript 생태계의 경우 다른 방법이 없기 때문에 선택할 수 있는 항목이 많습니다. 즉, 가장 인기 있는 옵션 중 일부는 Sequelize 및 Prisma 입니다 . 이러한 프레임워크는 개체를 데이터베이스의 테이블에 매핑하는 방법을 제공하고 개체 지향 구문을 사용하여 데이터베이스를 쿼리하는 방법도 제공합니다.

ORM 프레임워크 사용의 이점 중 하나는 작성해야 하는 상용구 코드의 양을 줄이는 것입니다. 또한 코드를 수정하지 않고도 기본 데이터베이스 스키마를 쉽게 변경할 수 있습니다.

그러나 ORM 프레임워크는 약간의 성능 오버헤드를 발생시키고 복잡한 쿼리(예: 복잡한 JOIN 및 하위 쿼리)를 수행하기 어렵게 만들 수 있으므로 애플리케이션에 적합한 프레임워크를 선택하는 것이 중요합니다.

ORM이 추가하는 모든 이점 외에도 Bit는 데이터 구조를 쉽게 공유하는 여러 프로젝트에서 데이터 모델과 일반 코드를 재사용할 수 있도록 함으로써 훨씬 더 많은 가치를 추가합니다. 예를 들어 특정 데이터 모델을 정의하는 ORM 구성 요소를 만든 다음 애플리케이션의 다른 부분에서 재사용할 수 있습니다. 이렇게 하면 동일한 코드를 여러 번 작성할 필요가 없기 때문에 시간과 노력을 절약할 수 있습니다. 또한 Bit를 사용하면 구성 요소를 쉽게 관리하고 버전을 지정할 수 있으므로 모든 구성 요소가 최신 상태이고 데이터 구조의 현재 버전과 일치하는지 확인할 수 있습니다.

읽은 내용이 마음에 드셨나요? IT 산업에서 얻은 20년의 지혜를 모든 사람과 공유하는 무료 뉴스레터 구독을 고려해 보십시오 . " 오래된 개발자의 방황 "에 참여하세요!

테스트 프레임워크

DDD(Domain-Driven Design)에서 테스트할 때 도메인 모델이 올바르고 예상대로 작동하는지 확인하는 것이 중요합니다. 여기에서 테스트 프레임워크가 필요합니다. 테스트는 소프트웨어의 최종 논리가 기대치를 충족하도록 도메인 모델을 어떻게든 설명해야 합니다.

JavaScript에 사용할 수 있는 많은 테스트 프레임워크가 있으며 각각 고유한 강점과 약점이 있습니다.

JavaScript용으로 매우 인기 있는 두 가지 테스트 프레임워크는 Jest와 Mocha입니다.

Jest 는 Facebook에서 만든 JavaScript 테스트 프레임워크입니다. 간단하고 직관적인 테스트 API를 제공하여 JavaScript 코드에 대한 테스트를 쉽게 작성할 수 있습니다. Jest는 모킹 및 스냅샷 테스트와 같은 기능도 제공하여 보다 효율적이고 효과적인 테스트를 작성하는 데 도움이 됩니다.

Mocha 는 원하는 스타일로 테스트를 작성할 수 있는 JavaScript 테스트 프레임워크입니다. 동기 및 비동기 코드를 모두 테스트하는 데 사용할 수 있는 유연한 API를 제공합니다. Mocha는 또한 여러 보고 형식을 지원하므로 테스트 워크플로우에서 다른 도구와 쉽게 통합할 수 있습니다.

Jest 또는 Mocha와 같은 테스트 프레임워크를 사용하면 버그를 포착하고 도메인 모델이 예상대로 작동하는지 확인할 수 있습니다. 그러나 테스트를 설정하고 항상 테스트를 실행하는 것은 시간이 많이 걸리고 지루할 수 있습니다. 이것이 Bit가 도울 수 있는 곳입니다.

Bit는 생성하는 모든 단일 구성 요소에 대한 테스트 템플릿을 자동으로 생성합니다. 뿐만 아니라 테스트 단계는 모든 주요 프로세스(예: 태그 지정 및 구성 요소 빌드) 내에서 필수이므로 원하지 않더라도 테스트를 작성하여 구성 요소를 푸시할 수 있는지 확인해야 합니다. 다른 개발자와 공유됩니다. 무엇보다도 Jest(또는 원하는 테스트 프레임워크) 설정은 Bit에 의해 자동으로 수행되므로 해당 단계에 대해 걱정할 필요가 없습니다.

결론적으로 DDD(Domain-Driven Design) 원칙을 사용하여 애플리케이션을 개발할 때 테스트 프레임워크를 사용하는 것이 중요합니다. Jest와 Mocha는 모두 JavaScript 애플리케이션 테스트에 널리 사용되는 선택이며 Bit를 사용하면 테스트 프로세스를 간소화할 수 있습니다. 이렇게 하면 시간과 노력을 절약하고 테스트가 최신 상태로 올바르게 작동하는지 확인할 수 있습니다.

요약하면 DDD(도메인 중심 설계)는 도메인 모델을 구현과 일치시키는 데 중점을 둔 소프트웨어 시스템 개발을 위한 강력한 방법론입니다. DDD를 지원하기 위해 이벤트 소싱, CQRS, 도메인 모델링 도구, ORM 프레임워크 및 테스트 프레임워크를 비롯한 다양한 도구와 기술을 사용할 수 있습니다.

또한 Bit를 사용하면 팀이 특정 비즈니스 기능을 캡슐화하는 구성 요소를 만들고 공유할 수 있습니다. 이는 DDD에 의존하는 복잡한 애플리케이션을 구축하고 유지 관리하는 데 중요합니다. 구성 요소를 사용하여 도메인 모델을 구축하고, 데이터베이스와 통합하고, 복잡한 비즈니스 로직을 수행할 수 있습니다.

따라서 DDD를 이제 막 시작했든 노련한 전문가이든 이러한 도구와 기술은 비즈니스 요구 사항에 맞는 더 나은 소프트웨어 응용 프로그램을 구축하는 데 도움이 될 수 있습니다.

그러니 계속해서 시도해보고 가장 적합한 것이 무엇인지 확인하십시오!

더 알아보기