很多项目可能还要加个工具层，用来放一些常用的工具类。但是工具类这个东西，与项目有关的可以放在这里，如果是多项目之间可以复用的，最好用更专业的做法：单独管理维护，打包成Nuget包(maven包)，由各个项目进行调用。
4.2 DDD分层代码模型按照 DDD 分层架构模型设计出来的代码模型应该长什么样子呢？
如上图所示:
用户接口层
Controller:提供较粗粒度的调用接口，将用户请求委派给一个或多个应用服务进行处理
DTO:数据传输的载体，内部不存在任何业务逻辑，我们通过 DTO 把内部的领域对象与外界隔离。
Mapper: 实现 DTO 与领域对象之间的相互转换和数据交换。
应用层
Event:存放事件相关代码，可以进行事件的发布和处理。事件发布和订阅放在应用层，事件相关的业务逻辑放在领域层。
Service：对多个领域服务或外部应用服务进行封装、编排和组合，对外提供粗粒度的服务。应用服务主要实现服务组合和编排，是一段独立的业务逻辑。
领域层
Aggregate：是Entity、Event、Service、Repository的根目录，聚合内实现高内聚的业务逻辑，可以根据实际项目中业务的聚合名称命名。在聚合内定义聚合根、实体和值对象以及领域服务之间的关系和边界。如果我们的项目需要进行微服务的拆分，那么一个聚合里的内容可以拆分为一个单独的服务。
Entity：用来存放聚合根、实体、值对象以及工厂模式（Factory）相关代码。实体类采用充血模型，同一实体相关的业务逻辑都在实体类代码中实现。跨实体的业务逻辑代码在领域服务中实现。
Event：存放事件实体以及与事件活动相关的业务逻辑代码。
Service：存放领域服务代码。一个领域服务是多个实体组合出来的一段业务逻辑。领域服务封装多个实体或方法后向上层提供应用服务调用。
Repository：存放所在聚合的查询或持久化领域对象的代码，通常包括仓储接口和仓储实现方法。为了方便聚合的拆分和组合，最好一个聚合对应一个仓储。
基础设施层
Config：主要存放一些配置相关代码。
Util：其它诸如数据库、缓存、文件，第三方类库相关的代码可以在这个目录下建立子目录。
在DDD的代码模型中需要注意的是:
分层的概念一定要清晰，明确各层的职责。
聚合的代码边界一定要清晰，聚合之间一定是松耦合低关联的。
小结毫无疑问，项目中选择合适的分层架构并设计一个优秀的代码模型有着巨大的好处，但实际上无论是三层架构还是DDD分层架构都没有明确的规定其标准的代码模型。因此以上两种代码模型仅供大家参考。
而经常会有些设计者在设计的时候总喜欢“炫技”，设计出来的代码模型“深奥复杂”、晦涩难懂，美其名曰“高大上”。熟不知大道至简，优秀的设计是用简单的方式解决复杂的问题，而不是把简单的问题复杂化，在解决问题的基础上，简单实用才是正途！
最后，希望每个项目都能有一个好的设计人员，结合实际情况，设计出一个好的代码模型，利己利人！