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