这里的土牛是指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 多个应用层

• 为每种应用程序类型创建单独的应用程序层。

• 使用单个领域层 共享核心域逻辑。