学习领域驱动设计DDD、软件架构、设计模式、最佳实践的包含Javascript案例
该项目的主要重点是就如何设计领域驱动六边形Domain-Driven Hexagon软件应用程序提供建议。本自述文件介绍了从不同来源收集的一些技术、工具、最佳实践、架构模式和指南。
代码示例是使用NodeJS、TypeScript、NestJS框架和Typeorm 编写的，用于数据库访问。
虽然这里介绍的模式和原则与框架/语言无关，但上述技术可以很容易地用任何替代方案替换。无论使用什么语言或框架，任何应用程序都可以从下面描述的原则中受益。
领域驱动六边形：
- 领域驱动设计 (DDD)
- 六边形（端口和适配器）架构
- 安全设计
- 清洁架构
- 洋葱架构
- SOLID的原则
- 软件设计模式
在我们开始之前，以下是使用这样一个完整架构的优点和缺点。
优点
- 独立于外部框架、技术、数据库等。框架和外部资源可以用更少的精力插入/拔出。
- 易测试和可扩展。
- 更加安全。一些安全原则在设计本身中就已经包含了。
- 该解决方案可以由不同的团队进行工作和维护，而不需要踩到对方的脚趾。
- 更容易增加新的功能。随着系统的发展，增加新功能的难度保持不变，而且相对较小。
- 如果解决方案沿着有边界的上下文线被适当地分解，那么在需要的时候，就很容易将其中的部分转换为微服务。
缺点
- 这是一个复杂的架构，需要对高质量的软件原则有坚定的理解，如SOLID、清洁/六角形架构、领域驱动设计等。任何实施这样一个解决方案的团队几乎肯定需要一位专家来推动这个解决方案，并防止它以错误的方式发展和积累技术债务。
- 这里介绍的一些做法并不推荐给没有很多业务逻辑的中小型应用。因此，实现这样一个完整的架构通常不适合于简单的CRUD应用，并可能使这种解决方案过度复杂化。下面描述的一些原则可以用于较小规模的应用，但必须在分析和了解所有的利弊之后才能实施。
简而言之，数据流看起来像这样（从左到右）。
- 请求/CLI命令/事件使用普通的DTO被发送到控制器。
- 控制器解析这个DTO，将其映射为命令/查询对象格式，并将其传递给应用服务。
- 应用服务处理这个命令/查询；它使用域服务和/或实体执行业务逻辑，并通过端口使用基础设施层。
- 基础设施层使用映射器将数据转换为它所需要的格式，使用存储库来获取/保存数据，使用适配器来发送事件或进行其他I/O通信，将数据映射回域格式并将其返回给应用服务。
- 在应用服务完成其工作后，它将数据/确认返回给控制器。
- 控制器将数据返回给用户（如果应用程序有演示器/视图，则返回这些数据）。
每一层都负责自己的逻辑，并且有构建模块，在可能和有意义的情况下，通常应该遵循单一责任原则（例如，只用Repositories来访问数据库，用Entities来处理业务逻辑，等等）。
请记住，不同的项目可以有比这里描述的更多或更少的步骤/层/构建块。如果应用需要，就增加一些，如果应用不是那么复杂，不需要所有的抽象，就跳过一些。
对任何项目的一般建议是：分析应用有多大/多复杂，找到一个折中的办法，根据项目的需要使用尽可能多的层/构件，跳过那些可能使事情过于复杂的层/构件。
每个步骤的更多细节点击标题