领域驱动设计之入门级教程
不知道本篇能否算作是入门级教程，因为大概构思了一下，里面有的是属于教程的东西，有的是相关的知识延伸，有的则什么都不是，就算是一点初级的认识吧，因为我也是接触不久。主要刚看完《领域驱动设计》，是一本不错的书。我看的是免费的pdf精简版，好像卖的话要$30，大家可以买来看看，应该是不错的。购买地址：http://www.lulu.com/product/paperback/domain-driven-design-quickly/2117794
文中提到软件设计有很多方法，其中一种较为出名的“瀑布设计”。过程就是业务专家提出需求，软件分析人员根据需求建立模型，然后开发人员根据模型进行编码，至上而下的瀑布模式。这个模式应该用了很多年，也应该有很多成功的案例。但是他应用的范围和年代都离我们远去，我想它应该是比较符合需求变化不大，或者是需求较为明朗。它的缺点也很明显，就是信息的流向是单向的，从业务专家-》软件分析人员-》开发人员，不存在信息的反馈（也可能是刚开始的时候，不需要反馈信息）。没有信息反馈的话，后面的一个环节就会根据自己的理解和认识加入自己的东西，就会离业务专家想要的东西越来越远，出来结果之后，就可能是返工开始的日子了。
另一个文中提到的就是：XP（ExtremeProgramming 极限编程）。书中应该是不太推崇xp，估计是和自己是讲DDD（Domain Driven Development领域驱动开发）有关系吧。敏捷出现的背景应该需求出现了问题，也就是需求的变化，而且是变更频繁，模型就会变更频繁，相应的文档也会变更频繁，开发的代码也就变更频繁。这时候，需要一种新的设计方法来支撑这种局面，改变一下大家的工作方式，于是乎“敏捷”诞生了。它推崇少些文档，不要过度设计，甚至是不要设计，以先满足目前的需求为准，进行代码开发，尽早的让客户看到可以运行的最终版本。等到需求变化了之后，再来进行重构，每一次只要满足当前需求就可以了，进行不断的迭代，越来越趋近于客户的想象。
虽然它解决了部分的问题，例如：文档没有更新造成的误解、过度设计带来的开发进度失控、复杂性的增加、多做了无用功，但是它也有很明显的缺点，就是它提倡的“简单”，对于简单大家都有自己的理解，同时缺乏了真是可见的模型之后，没有设计，由开发人员进行重构的代码会越来越难以阅读和更改。同时这也是我锁担心的，同时我个人对于敏捷也是保留的。
信息传递失真。
信息传递失真是说，信息在传递的过程中会迷失本来的意思，传递的环节越多，失真的度会越深，到最后可能就会变成另外一个样子。在http://www.zhiyonw.net/jjx1.htm中介绍了一下《信息失真成本》。
信息失真存在于各行各业，在我们的软件行业也不例外。书中就例举了例子，软件分析人员和业务领域专家在一起工作了几个月，一起创建了一个正确的模型，模型也代表了正确的领域知识。然后将模型交给开发人员之后，开发人员在看到模型之后，可能会发现在模型中的有些概念不能被正确的转换成代码，然后他们就会以模型为基础，加入自己的设计，虽然也可以实现模型，但是加入了很多自己的东西。随着开发的继续，更多的类被加入系统，原始模型和最终实现的差距就会越来越大。到最后，很难保证系统的质量，就算实现了，可是后面的维护呢？它能经得起实际环境的考验吗？后面还能扩展吗？都可能会出现问题的。
当然了，书中举这个例子，不光是为了说明信息失真的，好像就没有这个意思，是我自己想到的。它的本意是说一个模型虽然正确，但不代表它容易转换成代码，或者它的实现违反了不推荐的设计模式。这样的模型还是需要迭代的。我们应该选择一个更加容易和轻易转化成代码的模型。
产生上面问题的源泉就因为经过业务专家和软件分析人员建立的模型，对于开发人员来讲还是不适用的，有可能会违反软件设计原则，或者没有办法很好的实现，以为建立模型的时候没有考虑到开发这个因素。
书中给出的办法就是让开发人员参与到模型设计的过程中，减少模型在开发人员角度的失真，确保在设计模型的时候就考虑到后面的开发。
可是我觉得这也会产生问题。就是开发人员和业务人员的思考角度是不一样的，甚至可以说是反着的，过早的参与模型，这时候模型还处于业务分析的阶段，开发人员参与业务我觉得不太好。这个工作还是应该由架构师团队来完成，架构师也是开发经验丰富的人员，可以从开发角度来衡量模型的可性能，模型能否容易的转换成代码。可是减少后面开发的复杂性和不确定性。
所以说这个模型的建立除了业务专家、软件分析人员，还有一个重要的角色就是：架构师。架构师是联系业务和开发的角色。既可以尽早的参与模型的建立，发现业务流程的开发问题，为以后的开发扫清一些不必要的障碍。同时也可以思考后面的软件架构和硬件架构（部署等问题），后续工作的分配。
在我们创建软件的时候，有很多的功能是和要解决的业务领域没有关系的，他们是软件的基础部件，或者是为软件服务的。例如：权限、日志、数据访问、文件访问、网络访问、用户界面等。最好将这部分功能从业务领域分离开来，独立出来，因为这部分功能是相对稳定的，这样既保证了这部分的独立性，便于升级维护，不至于影响业务领域的功能实现，同时将业务功能，业务规则尽可能放在业务逻辑处理层。这样在以后如果修改业务逻辑，不至于需要修改基础部件，或者是修改散落在各处的业务逻辑代码。
还有一点好处就是利于自动化测试。可以对独立的模块进行自动化测试，以后修改模块或者重构模块，只要将模块对应的测试脚本跑一遍，没有问题的话，就说明修改或者重构是正确的，就可以集成到系统中。
因此，分层就是这个作用。将不同关注点的功能独立在一个层中，保证层的内聚性，每一层只依赖它下面的一层，减少耦合和依赖。
一个通用的领域驱动设计的架构性解决方案通常包含四层：
- 用户界面层，负责用户界面的展示。
- 应用层，处理用户的输入。
- 领域层，包含领域的信息，业务的核心所在，业务对象的持久化交给下面的基础设施层。
- 基础设施层，作为其他层的支撑存在。
将应用划分为独立的层，并建立层之间的交换规则，也即是层的接口，是相当重要的。
模块，一提起模块就好像进行面向过程开发时候的概念。其实在面向对象中，这个概念也是适用的。可以考虑先划分模块，保持模块的独立性，方便部署和重构，然后在每一个模块中应用分层的设计，便于层的升级和维护。最大限度的保持系统的可扩展性。
领域驱动设计使得我们可以一直专注于用户的业务领域，不至于偏离方向，应该说是一个永不过时的指导原则。