忘记Scala，Qi4J是下一个 Java? - Thinking In Jdon http://www.jdon.com/37099
Business Rules matters more很多聪明的程序员总是认为架构中底层的框架比简单的领域模型更加重要，比如OSGI可能就是一个比较底层的框架，很多人热捧它，但是它如果脱离简化领域模型就没有意义，领域模型是反映需求业务，是能够收到客户的钞票的，底层设施只是为这种目的实现的工具，别本末倒置了。如果我们更多程序员关注业务逻辑和领域模型，而不是关心事务 安全或框架的特点，软件生产力将得到真正加强。Evans DDD一书写得很好，但是真正实现起来比较困难，因为缺乏一个语法环境，而Qi4j正是提供这样一个语法环境，什么时候DDD起飞了，也是Qi4j起飞之日。If DDD takes off, Qi4J or frameworks like Qi4J will take off too.

类已经死亡，接口万岁Qi4j不只是一个框架，其实为我们指出现实中OO的误区。我曾经重构一个大型的BOSS，该BOSS使用Hibernate，屏蔽了数据库影响，基本都是使用面向对象设计，但是由于大量使用继承，导致耦合粒度太粗，结构混乱，这是OO之错？还是误用OO之错呢？
所以，在现实中，特别是领域建模时，使用继承会非常容易，可以说是直觉，但是使用接口才是设计，接口粒度要更细，至少有将行为和抽象分离的用处。如果框架提供这种行为和抽象的分离约束就非常好，但是又会导致贫血模型，所以，现实中设计就是在博弈：最大限度用接口，然后将接口嵌入模型中（这个模型就是Qi4j所说的组合模型了，因为它是拆了组合得出来的，就象1+1=2的组合结果2一样）。

使用qi4j实现DCI架构 - Thinking In Jdon http://www.jdon.com/38266

最后，该文总结了这样做的优点：以上代码可能多了些，但是能够完成代码的可读性, 代码的可维护性, 易于改变拓展性，如果你使用普通POJO方法，把所有职责放在一个类中，好像很简单了，一旦这个软件项目发展到一定程度，就难以拓展维护。此外还有优点是可以重用复用，能够避免贫血模型，在目前所谓主流架构Spring或EJB之中，你为了避免将所有行为方法放入一个大类中，将数据放在实体中，将行为分开放到服务Service中(见请问一下这样分层对不对)，这实际破坏了封装，就是MF指责的失血模型，问题摆在那里，但是一直没有得到解决， DCI架构解决了这个问题。

Qi4j提出面向组合编程思想 - 51CTO.COM http://developer.51cto.com/art/200711/60715.htm

DCI架构是什么？ - Thinking In Jdon http://www.jdon.com/37976
DCI可以使用Scala的traits方便实现，Java中可以使用AOP中的Mixin来实现，也是一种面向组合编程，这点DDD领域驱动框架Qi4j做得比较好。忘记Scala，Qi4J是下一个 Java?

Apache Zest http://zest.apache.org/

GitHub - apache/zest-java: Mirror of Apache Zest java https://github.com/apache/zest-java

--EOF--