Project Icon

modular-monolith-with-ddd

模块化单体应用的DDD实现示例

该开源项目展示了模块化单体应用的DDD实现方法。以.NET开发的会议组织系统为例,涵盖用户注册、群组管理、会议组织等核心功能。项目应用了面向对象编程原则和设计模式,并通过C4模型阐释了详细架构,为开发人员提供了实用的参考。

Modular Monolith with DDD

Full Modular Monolith .NET application with Domain-Driven Design approach.

Announcement

Learn, use and benefit from this project only if:

  • You condemn Russia and its military aggression against Ukraine
  • You recognize that Russia is an occupant that unlawfully invaded a sovereign state
  • You support Ukraine's territorial integrity, including its claims over temporarily occupied territories of Crimea and Donbas
  • You reject false narratives perpetuated by Russian state propaganda

Otherwise, leave this project immediately and educate yourself.

Putin, idi nachuj.

CI

FrontEnd application

FrontEnd application : Modular Monolith With DDD: FrontEnd React application

Table of contents

1. Introduction

  1.1 Purpose of this Repository

  1.2 Out of Scope

  1.3 Reason

  1.4 Disclaimer

  1.5 Give a Star

  1.6 Share It

2. Domain

  2.1 Description

  2.2 Conceptual Model

  2.3 Event Storming

3. Architecture

  3.0 C4 Model

  3.1 High Level View

  3.2 Module Level View

  3.3 API and Module Communication

  3.4 Module Requests Processing via CQRS

  3.5 Domain Model Principles and Attributes

  3.6 Cross-Cutting Concerns

  3.7 Modules Integration

  3.8 Internal Processing

  3.9 Security

  3.10 Unit Tests

  3.11 Architecture Decision Log

  3.12 Architecture Unit Tests

  3.13 Integration Tests

  3.14 System Integration Testing

  3.15 Event Sourcing

  3.16 Database change management

  3.17 Continuous Integration

  3.18 Static code analysis

  3.19 System Under Test SUT

  3.20 Mutation Testing

4. Technology

5. How to Run

6. Contribution

7. Roadmap

8. Authors

9. License

10. Inspirations and Recommendations

1. Introduction

1.1 Purpose of this Repository

This is a list of the main goals of this repository:

  • Showing how you can implement a monolith application in a modular way
  • Presentation of the full implementation of an application
    • This is not another simple application
    • This is not another proof of concept (PoC)
    • The goal is to present the implementation of an application that would be ready to run in production
  • Showing the application of best practices and object-oriented programming principles
  • Presentation of the use of design patterns. When, how and why they can be used
  • Presentation of some architectural considerations, decisions, approaches
  • Presentation of the implementation using Domain-Driven Design approach (tactical patterns)
  • Presentation of the implementation of Unit Tests for Domain Model (Testable Design in mind)
  • Presentation of the implementation of Integration Tests
  • Presentation of the implementation of Event Sourcing
  • Presentation of C4 Model
  • Presentation of diagram as text approach

1.2 Out of Scope

This is a list of subjects which are out of scope for this repository:

  • Business requirements gathering and analysis
  • System analysis
  • Domain exploration
  • Domain distillation
  • Domain-Driven Design strategic patterns
  • Architecture evaluation, quality attributes analysis
  • Integration, system tests
  • Project management
  • Infrastructure
  • Containerization
  • Software engineering process
  • Deployment process
  • Maintenance
  • Documentation

1.3 Reason

The reason for creating this repository is the lack of something similar. Most sample applications on GitHub have at least one of the following issues:

  • Very, very simple - few entities and use cases implemented
  • Not finished (for example there is no authentication, logging, etc..)
  • Poorly designed (in my opinion)
  • Poorly implemented (in my opinion)
  • Not well described
  • Assumptions and decisions are not clearly explained
  • Implements "Orders" domain - yes, everyone knows this domain, but something different is needed
  • Implemented in old technology
  • Not maintained

To sum up, there are some very good examples, but there are far too few of them. This repository has the task of filling this gap at some level.

1.4 Disclaimer

Software architecture should always be created to resolve specific business problems. Software architecture always supports some quality attributes and at the same time does not support others. A lot of other factors influence your software architecture - your team, opinions, preferences, experiences, technical constraints, time, budget, etc.

Always functional requirements, quality attributes, technical constraints and other factors should be considered before an architectural decision is made.

Because of the above, the architecture and implementation presented in this repository is one of the many ways to solve some problems. Take from this repository as much as you want, use it as you like but remember to always pick the best solution which is appropriate to the problem class you have.

1.5 Give a Star

My primary focus in this project is on quality. Creating a good quality product involves a lot of analysis, research and work. It takes a lot of time. If you like this project, learned something or you are using it in your applications, please give it a star :star:. This is the best motivation for me to continue this work. Thanks!

1.6 Share It

There are very few really good examples of this type of application. If you think this repository makes a difference and is worth it, please share it with your friends and on social networks. I will be extremely grateful.

2. Domain

2.1 Description

Definition:

Domain - A sphere of knowledge, influence, or activity. The subject area to which the user applies a program is the domain of the software. Domain-Driven Design Reference, Eric Evans

The Meeting Groups domain was selected for the purposes of this project based on the Meetup.com system.

Main reasons for selecting this domain:

  • It is common, a lot of people use the Meetup site to organize or attend meetings
  • There is a system for it, so everyone can check this implementation against a working site which supports this domain
  • It is not complex so it is easy to understand
  • It is not trivial - there are some business rules and logic and it is not just CRUD operations
  • You don't need much specific domain knowledge unlike other domains like financing, banking, medical
  • It is not big so it is easier to implement

Meetings

The main business entities are Member, Meeting Group and Meeting. A Member can create a Meeting Group, be part of a Meeting Group or can attend a Meeting.

A Meeting Group Member can be an Organizer of this group or a normal Member.

Only an Organizer of a Meeting Group can create a new Meeting.

A Meeting has attendees, not attendees (Members which declare they will not attend the Meeting) and Members on the Waitlist.

A Meeting can have an attendee limit. If the limit is reached, Members can only sign up to the Waitlist.

A Meeting Attendee can bring guests to the Meeting. The number of guests allowed is an attribute of the Meeting. Bringing guests can be unallowed.

A Meeting Attendee can have one of two roles: Attendee or Host. A Meeting must have at least one Host. The Host is a special role which grants permission to edit Meeting information or change the attendees list.

A Member can comment Meetings. A Member can reply to, like other Comments. Organizer manages commenting of Meeting by Meeting Commenting Configuration. Organizer can delete any Comment.

Each Meeting Group must have an organizer with active Subscription. One organizer can cover 3 Meeting Groups by his Subscription.

Additionally, Meeting organizer can set an Event Fee. Each Meeting Attendee is obliged to pay the fee. All guests should be paid by Meeting Attendee too.

Administration

To create a new Meeting Group, a Member needs to propose the group. A Meeting Group Proposal is sent to Administrators. An Administrator can accept or reject a Meeting Group Proposal. If a Meeting Group Proposal is accepted, a Meeting Group is created.

Payments

Each Member who is the Payer can buy the Subscription. He needs to pay the Subscription Payment. Subscription can expire so Subscription Renewal is required (by Subscription Renewal Payment payment to keep Subscription active).

When the Meeting fee is required, the Payer needs to pay Meeting Fee (through Meeting Fee Payment).

Users

Each Administrator, Member and Payer is a User. To be a User, User Registration is required and confirmed.

Each User is assigned one or more User Role.

Each User Role has set of Permissions. A Permission defines whether User can invoke a particular action.

2.2 Conceptual Model

Definition:

Conceptual Model - A conceptual model is a representation of a system, made of the composition of concepts that are used to help people know, understand, or simulate a subject the model represents. Wikipedia - Conceptual model

Conceptual Model

PlantUML version:

VisualParadigm version (not maintained, only for demonstration):

Conceptual Model of commenting feature

2.3 Event Storming

While a Conceptual Model focuses on structures and relationships between them, behavior and events that occur in our domain are more important.

There are many ways to show behavior and events. One of them is a light technique called Event Storming which is becoming more popular. Below are presented 3 main business processes using this technique: user registration, meeting group creation and meeting organization.

Note: Event Storming is a light, live workshop. One of the possible outputs of this workshop is presented here. Even if you are not doing Event Storming workshops, this type of process presentation can be very valuable to you and your stakeholders.

User Registration process



Meeting Group creation


Meeting organization


Payments Download high resolution file


3. Architecture

3.0 C4 Model

C4 model is a lean graphical notation technique for modelling the architecture of software systems.

As can be found on the website of the author of this model (Simon Brown): The C4 model was created as a way to help software development teams describe and communicate software architecture, both during up-front design sessions and when retrospectively documenting an existing codebase

Model C4 defines 4 levels (views) of the system architecture: System Context, Container, Component and Code. Below are examples of each of these levels that describe the architecture of this system.

Note: The PlantUML (diagram as text) component was used to describe all C4 model levels. Additionally, for levels C1-C3, a C4-PlantUML plug-in connecting PlantUML with the C4 model was used.

3.0.1 C1 System Context

3.0.2 C2 Container

3.0.3 C3 Component (high-level)

3.0.4 C3 Component (module-level)

3.0.5 C4 Code (meeting group

项目侧边栏1项目侧边栏2
推荐项目
Project Cover

豆包MarsCode

豆包 MarsCode 是一款革命性的编程助手,通过AI技术提供代码补全、单测生成、代码解释和智能问答等功能,支持100+编程语言,与主流编辑器无缝集成,显著提升开发效率和代码质量。

Project Cover

问小白

问小白是一个基于 DeepSeek R1 模型的智能对话平台,专为用户提供高效、贴心的对话体验。实时在线,支持深度思考和联网搜索。免费不限次数,帮用户写作、创作、分析和规划,各种任务随时完成!

Project Cover

白日梦AI

白日梦AI提供专注于AI视频生成的多样化功能,包括文生视频、动态画面和形象生成等,帮助用户快速上手,创造专业级内容。

Project Cover

有言AI

有言平台提供一站式AIGC视频创作解决方案,通过智能技术简化视频制作流程。无论是企业宣传还是个人分享,有言都能帮助用户快速、轻松地制作出专业级别的视频内容。

Project Cover

讯飞绘镜

讯飞绘镜是一个支持从创意到完整视频创作的智能平台,用户可以快速生成视频素材并创作独特的音乐视频和故事。平台提供多样化的主题和精选作品,帮助用户探索创意灵感。

Project Cover

讯飞文书

讯飞文书依托讯飞星火大模型,为文书写作者提供从素材筹备到稿件撰写及审稿的全程支持。通过录音智记和以稿写稿等功能,满足事务性工作的高频需求,帮助撰稿人节省精力,提高效率,优化工作与生活。

Project Cover

阿里绘蛙

绘蛙是阿里巴巴集团推出的革命性AI电商营销平台。利用尖端人工智能技术,为商家提供一键生成商品图和营销文案的服务,显著提升内容创作效率和营销效果。适用于淘宝、天猫等电商平台,让商品第一时间被种草。

Project Cover

Trae

Trae是一种自适应的集成开发环境(IDE),通过自动化和多元协作改变开发流程。利用Trae,团队能够更快速、精确地编写和部署代码,从而提高编程效率和项目交付速度。Trae具备上下文感知和代码自动完成功能,是提升开发效率的理想工具。

Project Cover

AIWritePaper论文写作

AIWritePaper论文写作是一站式AI论文写作辅助工具,简化了选题、文献检索至论文撰写的整个过程。通过简单设定,平台可快速生成高质量论文大纲和全文,配合图表、参考文献等一应俱全,同时提供开题报告和答辩PPT等增值服务,保障数据安全,有效提升写作效率和论文质量。

投诉举报邮箱: service@vectorlightyear.com
@2024 懂AI·鲁ICP备2024100362号-6·鲁公网安备37021002001498号