今天看了本有意思的书《领域驱动设计（Domain-Driven Design）》，看看序，还是大名鼎鼎的Mattin Fowler做的序，不过这个作者Eric Evans本来就挺有名吧，是我孤陋寡闻了，哈哈。

刚看了前言部分，很有些启发，和大家分享如下：

与其说是领域驱动，我理解更确切地说，是问题域驱动，因为程序就是一种面向问题域（Problem Domain）的解域（Solution Domain），这里的领域（Domain）强调的就是对问题域，比如我们要面对的业务领域。

领域驱动设计，就是基于对问题域的深入理解，对其进行精确的建模，然后结合适当的设计模式去解决问题。听上去和我们了解的其他方法没啥不一样？恩，还是很有些不一样滴！

首先，对问题域的理解，是不断深入的，需要业务和开发人员不断沟通。

这里就一是要求一种大家都能理解的语言——其实设计开发人员所用的UML和业务人员沟通，他们都是看得懂得，大家要用一种语言说事！

二是需要一个不断沟通的过程，在过程中不断求精，比如敏捷开发的过程，的确这种过程更符合人们认识事物的规律，瀑布式开发过程的静态文档不仅负担重，效果也不见得好，这里我们需要的是一个大家可以大量沟通的过程和工作方式，甚至在最初可以通过口头测试来验证。

其次，这里说的是精确的建模，怎么精确，我理解有这么几个层面。

首先是业务层面的精确，其实我们在开发过程中，经常发现，即便都是业务专家，同一个问题理解、表述也有差异，通过统一的建模语言，我们可以统一业务上的概念，甚至让业务人员对其业务理解也更深入；

其次这个模型表述是和实现绑定的，就是说我们一开始就可以用UML类图、对象图来表达概念。这个和我之前理解的不太一样，比如我们在需求阶段要尽量贴合业务，用业务语言来表述需求。但是这里面就会有转换，有误差甚至是错误。其实平心而论，我们在描述需求的时候，又何尝能摆脱实现的影子呢，需求特别是系统需求已经是涉及到了实现领域。那么索性，我们用精确的图来表达需求，当然我们的图一定要能表达业务，所以要精确。

第三，用适当的设计模式表达，怎么叫适当，这就需要设计人员能深入理解业务，把业务通过设计模式明确的表达。一般的开发人员都对业务知识不感兴趣，比如“这个我不关心，你只告诉我怎么做就行了”，对于一个好的设计人员，这是不对的！你首先要设法成为一个业务专家，至少能和业务人员用同样语言沟通，然后才能够很好运用自己设计模式的知识。

书上有一个例子，我的印象比较深，比如一个订货策略，如果你把他理解成一个需求点，那么很可能就埋没在代码里，加一句if..else判断就搞定，但是如果我们把这个策略设计成一个类（用策略模式）呢？不仅以后容易扩展，而且业务人员也很明白地看到，我的订货策略的确是通过你们的设计在表达的。笔者说，他的项目中，业务知识在不断的沟通中，不断补充到设计中，这真是让我们钦佩不已的局面！没有对业务深入的理解，对模式娴熟的运用，如何能做到?!

总之这本书，把过程、设计、业务领域知识建模这三者结合起来，是我有限的见识很少见到的，期待进一步学习！

ITPub博客

领域驱动设计——有意思的话题

最新文章