(105***89) 2012-05-09 13:20:25
潘老师，我看到领域驱动设计得到的是充血模型，从而又需要EDA去解决由此引发的问题，技术架构也变得复杂了，就设计成贫血模型有什么不好的
潘加宇 (3504847) 2012-05-09 14:00:16
不一定要多复杂的架构吧，能够做到通过对象的状态机封装业务逻辑，对外暴露该对象针对别的对象有意义的服务，就已经获得了对象的优势。
就算你所使用的框架是把数据和行为分离实现，只要能做到不要绕过行为去修改对象的数据，也可以获得对象的优势。
潘加宇 (3504847) 2012-05-09 14:01:23
思考一下"我给对象画的状态机管用吗"就可以了
攻略狂谷佳木 (761***33) 2012-05-09 14:25:48
如果一个对象状态的维护需要在多个线程间来回切换，效率要比不用对象低。所以当一个对象很"小"，一个线程的维护涉及到一组同质对象时，用面向对象会降低程序效率。
潘加宇 (3504847) 2012-05-09 15:55:26
程序员要操纵的抽象级别离计算机越远，肯定在"效率"上要作出牺牲。但是，对于"效率"的看法也在发生变化，毕竟硬件越来越便宜，有能力维护复杂软件代码的程序员越来越贵。所以，更看重在整个局面的大赢，在此前提下，局部出现不可调和的矛盾，可以放弃面向对象的实现。 很多时候，其实"效率"的要求没有那么夸张，有时候一说，开发人员就反应性地张口就来"会不会降低性能啊"，把这个当作拒绝深入思考的挡箭牌。
这么说吧：如果能用对象的思考方式把问题想清楚，就算你不用对象的手段来实现，也是很有帮助的。如果以"效率"为由拒绝作进一步的思考，软件的复杂性也不会平白无故就消失了。
当然，目前国内的大多数项目，并不适合以面向对象（即分析设计工作流）作为改进的开始，而应该先改进业务建模和需求的技能。适合以面向对象开发做为改进点的团队是：（1）专注于一个领域很多年；或者，（2）需求不难捕获，但对软件的质量要求很高，如医疗设备。
明月落谁家 (812***44) 2012-05-09 15:59:13
支持潘老師【提示：此用户正在使用Q+ Web：http://web.qq.com/】
明月落谁家 (812***44) 2012-05-09 15:59:42
效率只有在真的有影響的時候才是問題
潘加宇 (3504847) 2012-05-09 16:00:05
(105***89) －－你现在做的项目的领域是？
(105***89) 2012-05-09 16:01:42
审批管理
Sebastian商 (35320595) 2012-05-09 16:02:39
可以理解为审批流程的管理吗？
(105***89) 2012-05-09 16:02:58
不是，只是审批信息管理
(105***89) 2012-05-09 16:03:10
不涉及业务
潘加宇 (3504847) 2012-05-21 13:09:21
如果只是专注于审批，审批就是系统的核心域，用"审批"这个核心域透镜来看各种事物事件，就可以得到核心域的模型