本篇为架构设计系列的第一篇，希望通过本系列转变自己的软件设计思想。不再只是单纯代码的搬运工，而要有自己的设计想法。本篇也是领域驱动开发的第一篇。
之前第一次接触java的web编程开始，就被书里提前灌输了如下思想：jsp - action - service - serviceimpl - dao - daoimpl - 数据库。好像这就是一套标准一样，后来在教一个学弟写后端的时候，他问你这service也没干嘛啊，你这serviceimpl好像也没干嘛啊，对了，你这hibernate也没啥作用嘛，我直接用jdbc不就行了，然后被我一顿无情鄙视：小伙子，以后你接触大项目就知道了，要按部就班，这都是前人经验，遵守就行了。其实自己也觉得哪里不对劲，这就是所谓的知其然不知其所以然。对于层层调用早已习惯，因为逻辑简单，按部就班，总不会出错嘛，数据被代码一层层送到前端展示，再一层层被反馈给数据库。各层隔离，多好。其实往往是这样，你越不愿意提前动脑子，你以后费的精力就越多。
三层架构之殇
其实对于小型项目，或者简单逻辑，三层往往就够了，比如我之前做的一个参加比赛的作品，只是几句简单sql然后调用数据层层转到前端用echarts显示就非常的简单，对于大型项目来说，就比较麻烦了，如果你的数据表上了一定规模，那么任何一个数据库内容修改动作都会牵一发而动全身，你得修改对应实体，甚至业务逻辑，而如果一个项目经过几波接手流转，更加难以寻踪。以下部分内容提炼自该篇，如有需求，可以访问。
从三层架构迈向领域驱动设计 http://www.cnblogs.com/betterman/p/4408630.html
三层架构是什么
三层架构的结构
大家眼里通用的三层架构应该是这样的：
严格分层架构模式的特点是上层只能访问相邻的下层，其他层次间的调用都不允许。三层架构就是一种严格分层模式，它把职责划分为界面展示、业务逻辑、数据访问三层，还有一个业务实体，前面三层都要依赖它，所以它并不构成一个层。这里有个问题，严格分层架构只能上层访问相邻的下层所以我们时常会遇到这个问题，action想直接从dao拿数据，但非要经过service,或者现在做的.net开发，我必须通过provider来获取，虽然可以提升安全性和使组织架构更严密，但却写了很多重复的代码（空壳调用），这个得依据具体实现场景了。
三层架构的编程思想
三层架构的特点是一种面向过程的编程思想，特点如下：
- 业务实体类中基本上只有属性没有方法。 （深表认同，感觉没什么意义，单纯为满足orm）
- 业务逻辑层的类基本上只有方法没有属性。 （一系列接口的堆叠）
- 将数据表结构映射为业务实体类是一个惯用做法，以至于有人将其称之为“传统”。这样的好处是只需要理解一套模型，能够通过自动化工具从数据表直接生成业务实体，还能够自然而然的通过自动化机制存储与检索业务实体。但对于复杂点的业务，这样做就是绝大部分问题的根源。
- 当业务膨胀起来，需要划分模块的时候，我们有个常用的变形：提取一个服务层出来，用来组合模块间的交互，还为业务逻辑层提供了一个防腐层，可以把记录日志、验证权限、处理异常等职责分配给服务层
典型的结构：jsp — action –service —dao 再加个业务实体
上面介绍的就是我们常说的三层架构，由于采用了严格分层模式，用户界面层是绝对不能跨过业务逻辑层调用数据访问层的，同理服务层也是不能调用数据访问层。其实三层架构还有个更准确的名字—-分层贫血领域模型架构，这样就不管多少层都能概括了，但是这名字没有三层那么朗朗上口。前面名字中的领域模型指的是业务实体，贫血意思业务实体中没有或很少方法。
三层架构缺点
工作简单枯燥
从数据库搬到界面或从界面搬到数据库，长期重复枯燥的工作会让人感觉前途无亮
新增功能，需求变化
1，有些功能，它可能牵涉到了所有的数据表，做这样一个功能，首先要把所有关联到的数据表都找出来，理解清楚表与表之间的关系，比较痛苦的是别人写的代码你基本用不上，都要自己从头搞
2，不知道什么时候需求发生变更。
代码复用率低
不能复用那些久经考验的代码，导致重复代码慢慢积累，系统缺陷也比较多
反思三层架构
三层架构的最大问题在于：实际应用中人们喜欢把内存模型和数据库模型保持一致。三层架构的大部分问题都是从这里衍生出来的。
DDD的优势
三层架构到DDD的转变过程
初步动作
优化层次关系–>重构到面向对象设计–>使用DDD相关模式深入重构
上面讲到，三层是“分层贫血领域模型架构”，那么DDD则可称为“分层充血领域模型架构”。
三层到DDD的过程大体是这样的：
- 首先推翻严格分层的理念，采用松散分层来重新定义服务层（松散分层的意思是上层可以访问下层，而不只是相邻的下层），把调用数据访问层的职责交给服务层，接着把业务逻辑层移动到与业务实体在一起
- 再接着融合业务逻辑与业务实体，使之成为面向对象的设计，然后利用DDD的模式进行更深入的重构。在DDD技术掌握的还不是那么扎实的时候，三层技术基本仍然能够继续使用。
我们看到业务逻辑与数据访问层已经没有依赖关系了。
由于目前的服务层职责是非常轻的，甚至有很多空壳的调用，所以平衡一下职责，把调用数据访问层的职责从业务逻辑层提升到服务层，需要的数据通过参数传递给业务逻辑层。这样，对于那些简单到无业务逻辑的CRUD就不需要去访问业务层了，直接调用数据访问层。
注意：有些逻辑无法归类到任何一个业务实体上的，就让它留在原地，成为一个领域服务。有些逻辑连领域服务都无法归类的，就让它留在服务层，在坚持大方向的前提下，细节灵活处理，因为每次重构都能够让你对未来的路看到更清楚，很可能下一次重构后你就会为这些流浪逻辑找到合适的家了。
这就是简单模型：基础设施依赖领域层
深化动作
标准分层结构
正式介绍一下DDD的分层架构，当然DDD的架构并不限于分层，现在还有六边形架构、CQRS、EventSourcing等技术可以选用，但是不要好高骛远，先把分层架构掌握好。我准备从标准的结构入手。
各层职责
用户界面层：
原版—-负责向用户展现信息以及解释用户命令。
补充—- MVC中V和C都属于UI层，V展现信息，C解析用户命令。UI像地图一样把各个控制器关联了起来。
应用层：
原版—-很薄的一层，用来协调应用的活动。它不包含业务逻辑。它不保留业务对象的状态，但它保有应用任务的进度状态。
补充—-协调应用的活动这句话太抽象了，我充实一下它：从数据访问中获取领域对象，调用领域对象的方法完成任务，然后再调用数据访问代码把领域对象的改变持久化。事务、权限检查、记录日志、处理异常的职责也归它管。这点和前面三层的服务层的职责其实是一样的。
领域层：
原版—-本层包含关于领域的信息。这是业务软件的核心所在。在这里保留业务对象的状态，对业务对象和它们状态的持久化被委托给了基础设施层。
补充—-业务对象的持久化工作我们已经提升到应用层了，一般情况下，这层最好不要涉及资源库的调用，但是并不绝对。资源库的抽象要么在领域层中，要么提升到了“应用程序框架”，领域层是不会依赖基础设施的。
基础设施层：
原版—-本层作为其他层的支撑库存在。它提供了层间的通信，实现对业务对象的持久化，包含对用户界面层的支撑库等作用。
补充—-这层的职责包含了三层的数据访问，但是并不代表UI层就可以调用数据访问的代码，而且职责范围扩充了，有人可能会把它当作存放公用代码的地方，但是建议这里只存放本项目公用的东西，如果能够跨项目公用的代码应该放在一个叫做“应用程序框架”的项目来完成，每个公司都应该有自己的应用程序框架。
回顾一下三层架构与DDD分层的区别：
a. UI层技术基本一样，一些比较智能的绑定可能无法进行了。
b. 服务层基本一样。
d. 业务实体+业务逻辑 = 领域层
e. 如果三层架构不采用业务实体与数据表一致的做法，这层也是一样。
TML标题分割线=======================
开发过程回顾
典型的三层架构开发过程
三层架构以数据库为核心，首先根据需求建立数据模型，然后根据数据模型建立数据库，再根据数据表结构自动生成业务实体，然后可以同时进行业务逻辑及用户界面的开发。
1，一旦开发中业务有所变动，那么首先要修改数据库，重新生成实体，然后其他开发小朋友才能继续工作，网络连接不好、数据库挂机、数据库管理员未能及时更新数据库等等原因都会导致开发过程被打断，好处是终于可以休息一会，坏处是由于要赶进度晚上可能得加班。
2，经常变更数据库结构总不是一件愉快的事情，为了避免数据库结构变动，要求编码阶段之前尽量要把需求固定下来，中后期越少变动越好。由于业务逻辑与数据库绑定紧密，所以单元测试困难重重。当性能出现问题的时候，到底是代码逻辑没有写好，还是Sql语句没有写好，诊断有点困难。由于类的粒度太大，设计模式罕有用武之地，设计原则跟自己没有关系，久而久之可能会觉得编程思想都是骗人的。
DDD开发过程
DDD以领域模型为核心，首先根据需求建立领域模型，然后根据领域模型建立代码模型，然后就可以同时开发业务逻辑和用户界面了。
1，我们有一个模拟数据库存储接口的内存数据库，因此这时候不需要考虑数据库，如果这时业务发生变化，直接修改对象结构是非常简单的事情。直到开发后期，所有功能都已经开发完成，业务结构也稳定下来了，我们再根据领域模型建立数据库，进行一个简单的与业务逻辑集成就完工了。
2，免除了开发过程中数据库经常变动的烦恼，开发过程不会被打断，随时可以进行单元测试，随意可以与用户界面集成把系统跑起来，开发逻辑的时候不考虑数据库，开发数据库的时候不考虑业务，关注点更加集中了。出现性能问题可以单独测试数据库组件和业务逻辑组件，更容易定位问题。类的粒度很小，各种重用，各种设计思想都纷纷派上用场，感觉终于跟国际接轨了。
初识DDD
经过了以上博文的阅读归纳后，话是有些不知所以，觉得隐约确实好一些，但好处体现的似乎很模糊，初步体验就是三点：
1，开发初期邀请领域专家介入，使用通用语言沟通，更好的明确需求与业务。
2，将对数据表驱动开发的模式思路转换为业务，领域驱动开发的模式思路。具体操作就是，先建立领域模型，而不是数据模型，这样便于后期的修改和扩展。
3，将单纯的实体改为领域对象，使用充血模式开发，而不是贫血模式开发，这样不容易导致健忘症。
之后在看一本vaughn Vernon的《实现领域驱动设计》一书，会逐渐更新这方面的博客，争取在自己有架构能力（虽然很遥远）的时候实现直接使用领域驱动开发模式来架构。
