DDD 你是如此纠结！

楼主恭喜你已经触碰到DDD核心。

有一个问题我搞不清楚，这个问题是：整个世界底层的运行景象和运行原理是否真的和计算机底层的运行景象和运行原理是一样的？
如果这个问题的回答最终是“是”的话，就可以像理解现实世界一样去理解计算机世界，像理解计算机世界一样去理解现实世界了。虽然现实世界底层的景象和原理太难描述了，但是计算机世界描述了它。
对现实世界的理解和对计算机世界的理解如果真能打通的话，剩下的就是“从上而下”和“从下而上”了。有时候从现实世界的问题领域出发是从上而下，从计算机的问题领域出发是从下而上，一上一下相遇在中间层组合出一层“体”。
现实的问题世界和计算机的问题世界是互为上下的，比如计算机世界的底层再往下追溯就又跑到了现实物理世界去了。整个世界可能是个环状的东西，对于整体来说无所谓上和下，只是对于局部来说会有上下之分。
我们作为主体，我们是整个世界的局部，对于我们来说位置靠近我们的就是上，位置远离我们的就是下，位置靠近我们的我们处理起来对于我们来说就符合构造定律就节能，位置远离我们的我们处理起来就不节能，但是计算机处理起来可能节能，而计算机能被我们处理，问题要是能被识别为计算机那样的模式，我们就可以像处理了半个多世纪的计算机问题世界那样去处理现实问题世界了，一旦识别出这个分形的模式后结果又变的符合构造定律又节能了。
领域驱动设计大部分时候是从上而下，但如果宇宙真的像计算机世界那样运行的话，由计算机从下而上的去解决问题也可行。
[该贴被luda于2015-05-20 09:27修改过]

业务对象抽象出来，是ddd核心，名字很重要，代表一个边界。

其他都是落地必须的过程和手段，cqrs是ddd落地框架，这是一个境界问题，多年的沉淀和研究，让人误以为明白的不说明白话。其实不是隐藏，而是真理有时候确实无法说出来。

记得达摩和弟子说：知者不言，言者不知。意思是知道的人，他无法用语言表达境界（真相），所以也就不说了，怕误导，所以都是用隐喻。

ddd伟大之处在于，在更深的境界来说，具有很强的功力，也就是说，可以无限优化，你有多大能力，就能设计出多好的系统核心。

我这么多年的经验告诉我，捷径是没有的，因为功夫多深，是时间和沉淀修出来的。

下面是我开发的 node/javascript 版 cqrs框架，可以作为参考，javascript所有人都看得懂。结合了 actor ／ ddd ／ cqrs ，因为我觉得这三者打散后，从新组合起来的。思想是ddd，采用了cqrs的事件方式，用actor代表聚合根对象。

https://github.com/liangzeng/cqrs

安装方法 npm install cqrs

@banq banq老师您说我摸到核心，但是我感觉自己一片迷惘中。不知道到底如何是正确的ddd建模。想看看jlive源码，但是没找到哪里下载。能发个下载链接吗？
@brighthas 好东西！
但是我DDD没理透， 再好的框架也玩不转啊。

@luda
感觉不是ddd有问题， 而是世界太复杂。
对象的规划，对象的粒度，对象的责任，都难以确定。
而且虽然世界是客观的，但是每个人对世界的认识又不样。

非常希望有一个“得道高手”能教我们如何抽取对象，对象责任如何划分。
就比如图书管理系统中， 借书这个业务 到底是哪个对象的责任。为什么？而现在很多高手都是给你一个框架说这是ddd框架，然后你自己去搞吧。这其实对于初学者没有多大意义。 领域驱动设计， 领域如何建模都不知道。
谈什么框架， 谈什么cqrs， Event Sourcing 等等其他别的东西。 而显现建模才是ddd的核心。
所以个人认为在未“得道”之前，还是使用传统数据库模式为好。 不然搞的东西，不伦不类，而且复杂无比，得不偿失。
[该贴被tecentID68055于2015-05-22 17:24修改过]

不能为了使用某项技术或某个模式，从一开始就去做复杂的设计。

我认为应该从具体的工程中去不断地抽象，如果你的代码能很好地干活，你添加一个功能也没那么复杂，那就别管它了。直到你觉得增加一个功能变得复杂了，感觉和某些部分重合了，不断地在复制粘贴了，觉得代码很乱了，这时应该考虑去抽象了。

我认为模式是在具体的场景中形成的，形成后又能应用于同类场景。但不一定从一开始就发现它，可以随着变更需求来慢慢接近它。