到底是SOA还是DDD
当下潮流是铺天盖地的SOA啊，似乎不讲SOA就是一种落伍，一地的SOA，就像当初一地的java，一地的鸡毛。想当年，我们从c转到java，改变了什么？更多的项目是改变了编程语言而已（仅指后端业务逻辑）。可是我们推崇java，推崇的是它的开放，它的OO，并不是语言本身（好吧，语言确实也解决了一些内存问题、跨平台问题，只能说是降低了准入的门槛）。现在的SOA也是这样，我理解SOA讲的更多的是系统的治理，并非编程模型上的事情（厂商讲SOA讲的神乎其神的，似乎只要SOA了，你的系统就灵光了，什么问题都解决了，那是他们要卖中间件
），我看到的一个潮流时所谓的信息服务+服务/流程编排，实现所谓彻底的SOA，大家想想，这个和以前的面向过程编程有什么区别？如果一定要找出区别，区别就是用了中间件写程序，这部分逻辑号称不是硬编码，力度细到这种程度，和硬编码的区别又有多大呢。这种设计方式，将数据和逻辑完全分离了，再没有一个聚合业务逻辑的地方，有的同学会说在服务类中聚合，那服务类以什么准则设计呢？按照面对对象？
发了下牢骚，讲讲自己的想法吧，欢迎大家拍砖。就像上文说的，我理解SOA将的是系统治理，他体现的是系统的外观，要求系统暴露的能力是合理的、逻辑内聚的、没有自我矛盾的、没有安全漏洞的，基于这些允许的能力之后，你可以根据需要进行组合（集合一个或多个系统的能力，形成新的能力），什么都能组合，什么都能配置，我认为是一种拒绝设计的消极的思想，认为自己预料不到将来的变化（那我们需要经验，需要行业专家干吗呢？）。真正系统内部的逻辑，我们还是要按照OO来设计，或者从更高层面的DDD，将对象的逻辑聚合起来，只有这样，才能有一个维度来聚合逻辑，才能降低对于信息层的依赖，使得缓存机制更加灵活（原来面向过程的所谓SOA组合信息服务，根本没法控制信息的访问，因为缓存的机制和信息的修改逻辑有关，而这部分逻辑被分散到了SOA服务编排中）。
工作非常忙，就不细节的写下去了，大概就是这个意思了，不知道现在有多少的java/j2ee系统是面向对象设计的，可能很少吧，OO的设计对人是有要求的，我的经验是OO的系统设计，扩展方便，重构频率低，质量高，特别适合做产品，工程就算了（国内的工程一项是扑人头，卖人头的，简单便宜就好，管它后续质量如何）。
好久不来啦，现在还有人玩博客吗？NND，工作总是那么的忙，为啥。
