Jdon文章《实战DDD(Domain-Driven Design领域驱动设计)》的跟帖
回复这个帖子前，先扯一点儿其它，谈谈“软件的算法和方法”。
“软件的算法和方法”这个标题很大，有不懂装懂、故意卖弄之嫌。但我要表述的内容很浅显，只是借用了“XX法”这样高深的名词来表达在软件开发过程中，我们所关注的两个明显区分的领域。
算法
记得我在93年学习软件开发的时候主要关注的应该是算法。比如为了实现长方体的旋转，如何用最快的方式实现矩阵变换。这就是算法。教科书里通常都会精解例 举若干种排序的代码。这也是算法。同样，采用不同的方式去遍历一个二叉树或“图”也是算法的范畴。那个时候的软件书籍，除了语言类的，绝大多数是这类的。
但 是，跟我同龄段的软件从业者z们大都逐渐发现了一个事实：中国软件产业的发展的主流走向了管理软件和业务软件的方向。为早年写下WPS、CCDOS、 CCED的精英们立下汗马功劳的精妙绝伦算法研究已经很难派上大的用场。只要你会用VB/PB/Delphi，通过Drag控件和凌乱的逻辑代码就可以实 现一套完整的OA、管理信息系统、图书馆管理软件或者财务软件。这其实是中国软件产业的一个悲哀。
我们的专家们说，“中国软件业的前途是管理软件而不是系统软件”。于是我们从流，于是今天我们热衷于讨论的是软件设计的“方法”，“算法”的问题可以通过调用别人的lib去解决。
没错，牛顿也是站在别人的肩膀上的。可是我们同样站在上面望去，看不到我们民族的肩膀。跑题了。转回来。
在算法研究舞台上的缺位，让我们把所有的精力都倾注在了“方法”的研究和讨论上。特别最近3年，由Java开发本身所引出的各种方法层出不穷，引得我们无限追捧。
方法
软件开发/设计方法是一个这个行业最不可缺少的基础。软件工程组织、软件设计模式、软件框架、编程规范、测试驱动开发包括MDD/DDD都应该算是广义上的软件设计方法的范畴。而各个概念专注的领域不同，解决问题的重点也同：
软件工程的各种方法的目标是：组织和管理人员、时间、目标、过程、质量甚至预算。
软件设计模式的目标是：组织和管理程序的跳转逻辑。btw，“跳转逻辑”这个名词不够OO，是过程编程的概念。但任何OO语言走到下面到了编译原理和运算原理一层，就转化成“过程”了。
编程规范的目标是：组织和管理代码、注释、文档和数据资源。
测试驱动开发(TDD)的目标是：组织和管理编码和测试的过程，并最终对软件质量进行控制和管理。
MDD/DDD的目标则是：组织和管理复杂软件实现结构上的分析和设计，以求得一套清晰的指导思想来指引软件设计者在面对大型软件需求的时候，能够进入“万变不离其中”的“自由王国”。
DDD
做为《实战DDD(Domain-Driven Design领域驱动设计)》的跟帖，终于罗嗦到DDD。
我感觉到，无论采用何种方法翻译DDD中的Domain都难以找到一个最合理的汉语词汇来表达DDD的思想。即便现在普遍采用的“领域”一词，也令人感到 晦涩。其实我们应该摒弃“望文生意”的方式。也许直接称其为DDD，把“DDD”当成跟Java一样的代号，然后再去理解其中所表达的思想，这样会对学习 更有帮助一些。
另外一个重要的认识是：尽管DDD现在很流行，但从前没有DDD（词）的时候，一样可以开发出优秀的软件。在DDD这个词出现之前，许多类似的概念都在软 件设计中大量采用了。也许你也用过，但从来没有提炼成一种“方法学”上的理论。Eric E.提炼了这个概念。这个概念必然来自于他的实践。
所谓“领域驱动设计”看样子是目前最难直接理解的概念之一（而且直译过来后跟汉语的语法出入很大）。但如果你能把DDD看成若干中“理论”中的一种，那这个概念就很好接受了。
首先，只要是“理论”，就会有很多流派。每个流派的理论都必然有其可取之处。DDD看似要成为主要流派之一的，那么初学者就可以暂时无条件的去接受它。这也是“站在别人肩膀”上的做法。——不要反驳“无条件”这个词，你不是也无条件接受了牛顿三定律么？
第二，只要是“理论”，初学者就大可不必去深究“为什么是这样”。没有4年5年6年的开发经验，就不要去质疑。否则你的质疑只能拿去印证“无知者无畏”这句话的真理性，或者直接陷入类似 《一个“Spring轮子”引发的血案》的血案的血案的血案中去。“理解”本身需要一个过程。经历丰满的程序员在实践过DDD后会感慨：“从前我为什么不这样做！”。软件开发初学者没有从前，必然也无法体会出先苦后甜的感受。
第三，只要是“理论”，总是但方面的。总有站得住脚和站不住脚的地方。“算法”是有其唯一性的，是可以被证明其正确性和极限性（“顶点”）的。而“方法” 则不具备唯一性的特质。歪用DDD中的一个词来阐释：某种方法在某些领域（Domain）中是优秀的，而在其它的（Domain）则可能并不合适。因此， DDD也不是放之四海而皆准的真理。
“软件的算法和方法”这个标题很大，有不懂装懂、故意卖弄之嫌。但我要表述的内容很浅显，只是借用了“XX法”这样高深的名词来表达在软件开发过程中，我们所关注的两个明显区分的领域。
算法
记得我在93年学习软件开发的时候主要关注的应该是算法。比如为了实现长方体的旋转，如何用最快的方式实现矩阵变换。这就是算法。教科书里通常都会精解例 举若干种排序的代码。这也是算法。同样，采用不同的方式去遍历一个二叉树或“图”也是算法的范畴。那个时候的软件书籍，除了语言类的，绝大多数是这类的。
但 是，跟我同龄段的软件从业者z们大都逐渐发现了一个事实：中国软件产业的发展的主流走向了管理软件和业务软件的方向。为早年写下WPS、CCDOS、 CCED的精英们立下汗马功劳的精妙绝伦算法研究已经很难派上大的用场。只要你会用VB/PB/Delphi，通过Drag控件和凌乱的逻辑代码就可以实 现一套完整的OA、管理信息系统、图书馆管理软件或者财务软件。这其实是中国软件产业的一个悲哀。
我们的专家们说，“中国软件业的前途是管理软件而不是系统软件”。于是我们从流，于是今天我们热衷于讨论的是软件设计的“方法”，“算法”的问题可以通过调用别人的lib去解决。
没错，牛顿也是站在别人的肩膀上的。可是我们同样站在上面望去，看不到我们民族的肩膀。跑题了。转回来。
在算法研究舞台上的缺位，让我们把所有的精力都倾注在了“方法”的研究和讨论上。特别最近3年，由Java开发本身所引出的各种方法层出不穷，引得我们无限追捧。
方法
软件开发/设计方法是一个这个行业最不可缺少的基础。软件工程组织、软件设计模式、软件框架、编程规范、测试驱动开发包括MDD/DDD都应该算是广义上的软件设计方法的范畴。而各个概念专注的领域不同，解决问题的重点也同：
软件工程的各种方法的目标是：组织和管理人员、时间、目标、过程、质量甚至预算。
软件设计模式的目标是：组织和管理程序的跳转逻辑。btw，“跳转逻辑”这个名词不够OO，是过程编程的概念。但任何OO语言走到下面到了编译原理和运算原理一层，就转化成“过程”了。
编程规范的目标是：组织和管理代码、注释、文档和数据资源。
测试驱动开发(TDD)的目标是：组织和管理编码和测试的过程，并最终对软件质量进行控制和管理。
MDD/DDD的目标则是：组织和管理复杂软件实现结构上的分析和设计，以求得一套清晰的指导思想来指引软件设计者在面对大型软件需求的时候，能够进入“万变不离其中”的“自由王国”。
DDD
做为《实战DDD(Domain-Driven Design领域驱动设计)》的跟帖，终于罗嗦到DDD。
我感觉到，无论采用何种方法翻译DDD中的Domain都难以找到一个最合理的汉语词汇来表达DDD的思想。即便现在普遍采用的“领域”一词，也令人感到 晦涩。其实我们应该摒弃“望文生意”的方式。也许直接称其为DDD，把“DDD”当成跟Java一样的代号，然后再去理解其中所表达的思想，这样会对学习 更有帮助一些。
另外一个重要的认识是：尽管DDD现在很流行，但从前没有DDD（词）的时候，一样可以开发出优秀的软件。在DDD这个词出现之前，许多类似的概念都在软 件设计中大量采用了。也许你也用过，但从来没有提炼成一种“方法学”上的理论。Eric E.提炼了这个概念。这个概念必然来自于他的实践。
所谓“领域驱动设计”看样子是目前最难直接理解的概念之一（而且直译过来后跟汉语的语法出入很大）。但如果你能把DDD看成若干中“理论”中的一种，那这个概念就很好接受了。
首先，只要是“理论”，就会有很多流派。每个流派的理论都必然有其可取之处。DDD看似要成为主要流派之一的，那么初学者就可以暂时无条件的去接受它。这也是“站在别人肩膀”上的做法。——不要反驳“无条件”这个词，你不是也无条件接受了牛顿三定律么？
第二，只要是“理论”，初学者就大可不必去深究“为什么是这样”。没有4年5年6年的开发经验，就不要去质疑。否则你的质疑只能拿去印证“无知者无畏”这句话的真理性，或者直接陷入类似 《一个“Spring轮子”引发的血案》的血案的血案的血案中去。“理解”本身需要一个过程。经历丰满的程序员在实践过DDD后会感慨：“从前我为什么不这样做！”。软件开发初学者没有从前，必然也无法体会出先苦后甜的感受。
第三，只要是“理论”，总是但方面的。总有站得住脚和站不住脚的地方。“算法”是有其唯一性的，是可以被证明其正确性和极限性（“顶点”）的。而“方法” 则不具备唯一性的特质。歪用DDD中的一个词来阐释：某种方法在某些领域（Domain）中是优秀的，而在其它的（Domain）则可能并不合适。因此， DDD也不是放之四海而皆准的真理。