标签：问题 nbsp tps 计时 size ref 之间 images family
最近看了《领域驱动设计：软件核心复杂性应对之道》，从字面上来看领域驱动就是解决软件复杂性问题的；然而领域驱动设计的门槛很高，没有很深厚的面向对象编码能力几乎不可能实践成功。Martin Fowler在PoEAA一书中给了一个有力的解释：
我们把三层架构等除了领域驱动之外的架构方式都可以归纳为以数据为中心的架构方式，在图中是黑色的粗实线；
领域驱动设计在图中是绿色的粗实线。
这幅图形象的解释了领域驱动设计和传统的软件架构模式两者在软件开发过程中解决复杂性之间的差异。
所谓领域驱动设计，可以从三个方面理解：
领域：可以理解为就是一个问题域，有边界，只要是同一个领域，那问题域就相同，我们做任何一个软件系统，都是有原因的，否则就没必要做这个系统，而这个原因就是我们遇到的问题。一个超市系统就可以看成是一个领域，其他的和超市相似需求系统就能属于同一个领域，因为每个系统都要有商品的显示，顾客购买商品结账等功能；
设计:主要是领域模型的设计，每个领域都对应着一个模型设计，每一个领域，都有一个对应的领域模型，领域模型能够很好的帮我们解决复杂的业务问题；
驱动:领域驱动领域模型设计，领域驱动代码实现；
领域驱动设计（DDD）告诉我们的最大价值我觉得是：当我们要开发一个系统时，应该尽量先把领域模型想清楚，然后再开始动手编码，这样的系统后期才会很好维护。
总结：
领域就是问题域，有边界，领域中有很多问题；
任何一个系统要解决的那个大问题都对应一个领域；
通过建立领域模型来解决领域中的核心问题，模型驱动的思想；
领域建模的目标针对我们在领域中所关心的问题，即只针对核心关注点，而不是整个领域中的所有问题；
领域模型在设计时应考虑一定的抽象性、通用性，以及复用价值；
通过领域模型驱动代码的实现，确保代码让领域模型落地，代码最终能解决问题；
领域模型是系统的核心，是领域内的业务的直接沉淀，具有非常大的业务价值；
技术架构设计或数据存储等是在领域模型的外围，帮助领域模型进行落地；
开发系统要理解零领域，拆分领域，细化领域
领域知识软件设计的一部分，还有更多的设计 如：架构设计，数据库设计等；
领域驱动的学习是一个漫长的过程，所以在今后的项目实战中要不断总结，理解。
标签：问题 nbsp tps 计时 size ref 之间 images family
原文地址：http://www.cnblogs.com/LIUWEI123/p/6158189.html
