跟着“土牛”学架构知识
这里的土牛是指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 多个应用层
-
为每种应用程序类型创建单独的应用程序层。
-
使用单个领域层 共享核心域逻辑。
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
