ABP Framework 研习社经验总结(6.28-7.2)

阅读目录

 

目录

 

回到目录

ABP Framework 研习社经验总结(6.28-7.2)

研习社初衷

在翻译 《实现领域驱动设计》—— 基于 ABP Framework 实现领域驱动设计实用指南 时,因为DDD理论和实践的宽泛性,不同公司、不同行业、不同项目实现程度不同,觉得有必要为 ABP Framework 开发者提供一个良好的沟通、交流平台。

建群时间:2021.6.23 专注 ABP Framework 技术讨论、经验交流、资料共享!ABP Framework 研习社(QQ群:726299208) 欢迎更多的朋友加入,共同学习、共同成长!

十天回顾

首位成员:忘忧草 让人难忘!

ABP Framework 研习社经验总结(6.28-7.2)

截止到今日(7.2),10天时间,群里共入住182位小伙伴。

ABP Framework 研习社经验总结(6.28-7.2)

群里小伙伴,开发年限长,平时不闲聊,遇到感兴趣的话题,也会引发刷屏式的讨论。

入住大神级人物,@张善友(dotnet跨平台公众号作者,感谢文章推荐!) @角落的白板(52ABP框架作者)。

很多ABP元老级玩家,@娇龙(16年开始使用) @野鬼(15年开始用) @黑羽(在0.n版本时开始用)。

或许还潜伏着更多低调的高手,未被发现!

研习社经验总结(6.28-7.2)

总结和提取 ABP Framework 研习社 大家讨论活跃的话题、关注度比较高的内容,供各位学习、交流!

问题1:关于ABP版本

by@失意忆的誓言 15:21:50
现在是研究abp还是abp vnext

发现大家在沟通过程中对于ABP新旧版本存在不统一,所以觉得有必要梳理下ABP的版本。

简单回顾ABP的发展历史:

ASP .NET 时代

ABP Framework 研习社经验总结(6.28-7.2)

ASP .NET Boilerplate Project,简称ABP,是第一代开源框架。

ASP .NET Zero是基于 ASP .NET Boilerplate 框架的通用(模板)解决方案。付费商业版。

ASP .NET Core 时代

.NET Core 时代来临,ABP开发者考虑下一代版本的开发,开发代号Abp vNext,为了和第一代开源框架区分,这样命名很好理解,因为 .Net Core 之前也称为 .Net vnext 意为:下一代版本。

随着版本的逐步完善,个人感觉 ABP开发者的平台化战略越来越清晰,首先有一个统一平台 ABP.IO ,包括:文档、框架、社区、支持及商业服务,这不仅仅是一个官方网站,我们可以看到官方更大的愿景,围绕 ABP Framework 打造开发者生态,比如:插件商店也在未来的开发计划当中。

ABP.IO 平台之下,最核心是:开源框架 ABP Framework 和 商业版 ABP Commercial 。

这与 ASP.NET 时代下的 ASP.NET Boilerplate Project 和 ASP.NET Zero 相对应。

最新版ABP,准确地应该称之为 ABP Framwork 。

ABP历史小结

  • ASP.NET 时代
    • ASP.NET Boilerplate Project 开源框架
    • ASP.NET Zero 商业版
  • ASP.NET Core 时代
    • Abp vNext 前身
    • ABP.IO 平台
      • ABP Framework 开源框架
      • ABP Commercial 商业版

问题2:关于DDD和三层架构区别

问题:三层架构和DDD究竟有什么不一样?

最大的区别在于设计思想的不同:DDD以领域为中心;三层以数据库为中心。一个是领域驱动;一个是数据驱动。DDD使用领域对象封装和实现需求的复杂性,领域可以复用;三层架构基于数据库建模,常规操作为:CRUD。

ABP Framework 研习社经验总结(6.28-7.2)

问题3:ObjectMapper是不是和领域服务有些冲突?

问题 by@黑羽:因为有了自动映射会导致可能不走构造函数,进而导致不走领域模型的构造函数中的业务逻辑?
@黑羽:我现在就是觉得 mapper违背一些规则。一开始觉得还行,后来觉得很不好用。

自动映射常用在领域服务中,接收参数,将 (输入)数据传输对象 转换为 领域对象返回数据,获取 领域对象 转换为 (输出)数据传输对象 。

接收参数转换为领域对象,如果创建领域对象时,需要属性有效性验证,不推荐使用 自动映射,尽管可以通过设置 自动映射规则,不建议将 业务规则 隐藏在自动映射配置中。

因为数据传输对象是一个POCO对象,所以在将 实体 自动映射为 (输出)数据传输对象时,可以放心自动映射。

对象自动映射,不是实施领域驱动必须技术,当做是一个工具,酌情使用即可!

更多最佳实践可以参看:《基于ABP Framework 实现领域驱动设计》#构件/数据传输对象/对象映射 章节

问题4:求 IssueTracking 项目源码

Hager²º20 08:22:55
@iEricLee 群主早上好,看了你的文章,质量很高呀。提到的项目IssueTracking,有没有可能给分享一份,具体的学习学习。

失意忆的誓言 08:28:15
那有没有最佳实现方式的demo可以分享一下呢,麻雀虽小五脏俱全的那种

@Hager²º20 如果能有一个示例项目结合文章细品就更好了
DDD这玩意儿,就是一种设计思想,可具体落地时有时候就感觉无从下手。

这里统一做一个回复:IssueTracking 是一个虚拟项目,主要用来模拟业务场景和需求的演变,目前没有与文章中相对应的单独项目。

如果大家想研究DDD落地后的项目示例,其实在 ABP Framework 源码中提供很多应用模块,这些应用模块都是遵循DDD最佳实践和原则,挑自己感兴趣的模块研究即可。

推荐最新发布的 CMS-Kit 模块传送门:Github 源码 。

问题5:关于应用层分层问题

问题:by@听她说。 它后面说可以多个application层来对应多个不同的业务场景 你能做个案例出来不

上一篇:DDD领域驱动设计


下一篇:12306核心场景DDD领域建模