DDD 架构中自己的一点理解。

先抛出一个问题，IRepository 放在Domain层合理吗？从传统的分层架构来说，不合理，Repository的接口需要定义在Repository的抽象层，但是我们DDD的初衷是使我们的Domain 领域模型尽量独立，尽可能少依赖外界，也就是高内聚，低耦合，让核心Domain业务逻辑尽量防止外界污染。如果Domain依赖外界的抽象层接口，那么如果外界接口变了我是不是要跟着变。软件变法基本核心业务逻辑变法不大，变法最频繁的是上到UI界面,下到存储方式的变法，所以从这个角度讲是合理的。我们分层本质为了什么，也就是划分一个边界 boundary. 让一个复杂的东西在局部是简单的。比如通讯协议的设计，底层通讯层只管理链接和二级制数据包，上层协议专注逻辑。说起DDD，觉得这个是一个通用的分层，这种划分基本通吃所有软件，不管是Web，WPF, Service, 还是Xamarin。那个软件业务没有核心业务逻辑，UI，存储。当然具体到每个行业内部，你可能有自己的分层标准，也不一定要严格按照DDD来分，只要能划分清楚边界的分层方式就是好方式。

实现DDD也有几种方式，

1.简单传统方式。Controller->Application->Domain->Repository->DB 这种的领域Entity基本都是贫血模型，都是为了和数据库做映射。业务逻辑也是写在DomainService里面。对于简单项目CRUD的完全够用了，上手容易简单。缺点就是不够灵活，需求变了需要修改老代码才能应对业务。就像曹操80万大军南下，船链船（service call service 紧耦合）适合人多势众但是人员整体质量不高的团队，这也是为什么这么多年DDD不瘟不火。

2.CQRS, 通过命令来驱动，有点WPF的思想，有了事件驱动为什么还要搞个命令出来，解耦了需要相互关联的对象，每个聚合根相互独立。需要通信可以通过订阅发布消息来实现。比如要添加新功能，需要重新添加一个消息处理器订阅所关心的消息，在新的消息处理器里面写新需求逻辑，满足开闭原则。灵活，但是上手没那么直观。而且读写分离，适合高并发的场景。其读取数据直接绕过Domain层(一般读取数据不需要验证，不想添加更新数据需要做数据验证)，通过Dapper之类库来映射成需要的对象输出到UI。