跟着“土牛”学架构知识

这里的土牛是指abp的作者,土耳其人,简称“土牛”,前两天看了他分享的ppt,这里做个小笔记。

架构分层

图一(abp作者)

跟着“土牛”学架构知识

图二(clean架构)

跟着“土牛”学架构知识

图三(在朋友圈看到的)

跟着“土牛”学架构知识

每种架构没有好坏,只要是流行的,适合自己的就好。一种架构不管是否完全运用DDD思想,不重要,合理的分层是必须的!

  • 表现层
  • 应用层(用例)
  • 领域层
  • 基础设施层

领域驱动的核心构件

跟着“土牛”学架构知识

最佳实践

Repositories 原则
  • repository 是一个类似于集合的接口,可与数据库交互以读取和写入实体
  • 在domain layer定义接口,在infrastructure中实现
  • 不包含domain 逻辑
  • Repository 接口应独立于数据库/ ORM
  • 为聚合根而非实体创建repositories
Application Services 原则
  • 实现应用程序的用例(应用逻辑)
  • 不实现核心domain逻辑
  • 获取并返回数据传输对象(DTO),而不是实体(entities)
  • 在内部使用领域服务,实体,仓储,和其他领域对象。
Application Services
通用DTO原则最佳实践
  • 应该序列化
  • 应该有一个无参数的构造函数
  • 不应该包含业务逻辑
  • 不要从实体继承!不要引用实体!
Input DTO 最佳实践
  • 仅定义用例所需的属性
  • 不要在多个用例(服务方法)中重复使用相同的输入DTO。

例如:

  • ID 在创建的时候不会使用!创建和修改不要共享相同的dto!
  • 密码在更改和ChangeUserName不会使用!
跟着“土牛”学架构知识
跟着“土牛”学架构知识

另外两个最佳实战

  • 仅实现形式验证(可以使用数据注释属性)
  • 不包括域验证逻辑(例如:唯一用户名约束)
Application Services
Output DTO 建议
  • 保持输出DTO文件数量最小。尽可能重复使用(不能把输入DTO作为输出DTO)。
  • 可能包含比客户需求更多的属性
  • 创建和更新方法返回实体DTO。
  • 例外:性能至关重要的地方,尤其是对于大型结果集。
跟着“土牛”学架构知识

vs

跟着“土牛”学架构知识
Application Services 对象映射
  • 使用自动对象映射库(但是,请小心–启用配置验证)
  • 不要将输入DTO映射到实体。
  • 将实体映射到输出DTO
Multiple Application Layers 多个应用层
  • 为每种应用程序类型创建单独的应用程序层。
  • 使用单个领域层 共享核心域逻辑。
跟着“土牛”学架构知识

原始PPT

github地址: https://github.com/hikalkan/presentations

跟着“土牛”学架构知识

原文出处:微信公众号【李明成 dotNET知音】

原文链接:https://mp.weixin.qq.com/s/XadgoLG3p6-sgWdGslaAfg

本文观点不代表Dotnet9立场,转载请联系原作者。

发表评论

登录后才能评论