昨天妹子让我帮她解决个问题，本以为可以轻松搞定，但是打开他们项目的一瞬间，我头皮发麻。本身功能不多的一个小项目，解决方案里竟然有几十个类库。仅仅搞明白各个类库的作用，代码层次之间的引用关系就花了一个多小时。
显然可能他们项目结构的代码模型出了问题，设计混乱，不容易上手。
项目中一个好的的代码模型一定是简单、清晰、明了、易于上手的。它总是会让人用起来很舒服，它可以让项目团队成员更好地理解代码，根据代码规范实现团队协作；它可以让各层的逻辑互不干扰、分工协作、各据其位、各司其职，避免不必要的代码混淆。它可以让我们的代码扩展性很好，可以让系统的可维护性更好......
而代码模型的搭建跟项目的分层架构有关系，绝大多数项目开发中都会会采用分层开发，它有着分散关注、松散耦合、逻辑复用、标准定义、扩展性强等众多好处。而在分层架构中最常用的有两种:三层架构和DDD(领域驱动)分层架构。我们选择的分层方式也决定了我们的项目结构中的代码模型。
1.三层架构三层架构是一种严格分层模式，而严格分层架构模式的特点是上层只能访问相邻的下层，其他层次间的调用都不允许。它把职责划分为界面展示、业务逻辑、数据访问三层，还有一个业务实体，前面三层都要依赖它，所以它并不构成一个层。
三层架构是一种面向过程的编程思想，它有几个特点
业务实体类中基本上只有属性没有方法。
业务逻辑层的类基本上只有方法没有属性。
在使用三层架构开发的时候我们通常会直接将数据表结构映射为业务实体类。这样的好处是只需要理解一套模型，以至于市场上也产生了一系列的代码生成工具可以一键生成实体和增删改查的代码。但对于复杂点的业务，这样做也会产生很多的问题。
而当业务不再是简单的增删查改时，我们可以在三层架构的基础上有个简单的变形：提取一个服务层出来，用来组合模块间的交互，还为业务逻辑层提供了一个防腐层，可以把记录日志、验证权限、处理异常等职责分配给服务层。
三层架构有一个显著缺点就是它的内存模型不是基于业务模型而是是基于数据库模型建立的。而很多时候我们的业务模型并不能和我们的数据库模型完全吻合。
例如：如果你的数据库模型的粒度很小。有些业务就需要连接多张数据库表才能实现。而如果数据库模型的粒度很大（这是大部分项目的选择），代码的质量（重用性、稳定性、扩展性）就很差。由于没有从业务的角度去仔细定义每一个对象，每个人会根据自己的需要建立各种QueryModel或ViewModel(相信三层架构用久了的同学都会遇到这个问题)。
而且现在很多大型系统都会采用分布式的架构，如现在的微服务架构。服务内不仅仅是简单的增删查改，会有更多的与其它服务交互的内容，而服务的拆分也是以业务模型为导向的。
这个时候DDD(领域驱动)分层架构就会更有优势。
DDD分层架构主要包含四层:用户接口层、应用层、领域层、基础层。
用户接口层：面向前端提供服务适配，面向资源层提供资源适配。这一层聚集了接口适配相关的功能。
应用层：位于领域层的上一层，理论上不应该有业务规则或逻辑。主要用来实现服务组合和编排，协作完成业务操作，负责处理业务用例的执行顺序以及结果的拼装，以粗粒度的服务通过 API 网关向前端发布提供安全认证、权限校验、事务控制、发送或订阅领域事件等功能。
领域层：实现领域的核心业务逻辑。这一层聚集了领域模型的聚合、聚合根、实体、值对象、领域服务和事件等领域对象，以及它们组合所形成的业务能力。
基础层：贯穿所有层的，为其它各层提供通用的技术和基础服务，包括第三方工具、驱动、消息中间件、网关、文件、缓存以及数据库等。比较常见的功能还是提供数据库持久化。基础层包含基础服务，它可以采用依赖倒置设计，封装基础资源服务，实现应用层、领域层与基础层的解耦，降低外部资源变化对应用的影响。
