结合我以前一篇帖子：依赖注入与事件编程

http://www.jdon.com/45264

文章提出了依赖注入的一个问题。

这里总结一下：

聚合 >松耦合>重用 ==> 事件驱动>依赖注入>继承

上面这篇文章是证明"事件驱动>依赖注入"，至于“依赖注入>继承”见这个帖子：使用组合+依赖替代继承案例，虽然使用的AngularJS的依赖注入，但是原理适合所有编程语言：

http://www.jdon.com/45895

相关参考：

http://www.jdon.com/designpatterns/ooprimer.html

[该贴被banq于2013-12-17 10:07修改过]

Spring 并不是SOA，尽管它很像（各种Service）。

Spring与SOA的问题应该是：他们的切分没有基于一个逻辑系统，所以往往会有冗余和空白。逻辑不是由一个个Service组成，而是由语言组成的（语言是逻辑的载体，曾经某道友提过“原语”，也是接近这意思）。Service并没有语言特性，也没有处于语言外的逻辑系统特性，于是它所切分的逻辑是混乱的。

让程序构成语言，再用语言表达逻辑，这才是出路，否则表达业务逻辑就是空谈。业务逻辑是逻辑，什么是逻辑？你的代码做到了吗？

对于依赖注入，这东西根本不是谈逻辑的。考虑传统编程思想，DI的最大问题是不在控制范围之内。无论高内聚低耦合，还是全内聚零耦合，我认为这些问题是特定语言引起的，思考下我们的自然语言，有考虑过这些问题么？

[该贴被SpeedVan于2013-12-19 10:05修改过]

赞同，它们其实类似一个以项目决定一切的公司，公司老总是销售出身，眼睛只盯客户，这其实是第一个层次朴素的经商理念，真正一流企业是做标准，是保持这个行业的领域创新的Number 1。

我在另外一个帖子：http://www.jdon.com/45998#23144164也谈了服务的定位以及与CRUD区别：

基于领域分析后的新Service服务如同一个broker，也就是商人，做倒进倒出生意，把工厂(领域)的产品卖给客户，自己并不生产产品(业务逻辑)。

至于CRUD放入数据存储中，也就是Respository仓储中，CRUD本来就是数据存储的概念，不是业务领域概念，这个前提是你的系统复杂，不是简单得只有CRUD，那么DDD不适用。

DDD是在CRUD基础上有复杂业务逻辑，SOA解决了CRUD基础上的流程逻辑，但是并没有解决领域逻辑，聚合以及聚合的状态变化，聚合状态是因为受到外部流程变动而变化，但是聚合状态不是全局变量，不是流程想改就改，得通过领域规则这一关。

打个比喻，居委会要举行选举，选举有选举的流程，其中一个步骤是通知你参加，但是你可以不参加，不能因为外部流程，你没有自己的领域规则。

所以，领域要和两个敌人做斗争，前面是商人SOA服务，后者是数据库，和这两者划清界限，领域层就自然出来了。

与数据库划清界限是有关建模方面参考：建模风暴：

http://www.jdon.com/45999

总体来说：在需求分析这块经历三个阶段：

数据驱动SQL ---->服务驱动SOA ----->领域驱动

一个结合领域驱动+服务驱动SOA+数据驱动SQL架构图应该如下：

[该贴被banq于2013-12-19 12:51修改过]

"这两个服务都依赖PricePlocy，就算PricePlocy是个接口，如果接口发生变化，这两个服务的代码就发生变化。"

“依赖注入”还有个名字“控制反转”，因此前述语句的问题在于没有彻底理解“反转”一词，接口应该是调用方定义和实现，实现一般采用适配器模式来做，因此，接口是调用方拿来隔离调用依赖变化的，变化即隔离在适配器实现中，唯一不变的是变，变是好事，变是成长，关键是如何隔离变，“反转”至关重要！