MVC模式:Model模型 View试图 Control控制器，是目前主流模式，被当作服务器软件入门基本模式学习和掌握，主流框架Struts 1/2 JSF Wicket基本都顺理成章支持MVC模式。
但是，随着时间推移，MVC模式也暴露出大量缺点，因为MVC模式本质上是一个结构型模式，结构模式相比行为模式而言，实际就是静止的，相对固定的，而随着B/S和互联网应用不断普及，Web 2.0和社会化媒体 以及游戏等大量频繁交互应用普及，相对静止的MVC模式已经不适合高度交互注重行为的应用了。
DDD领域建模本身比较重视结构，它的实体 值对象和服务器是也是一种结构划分，但是没有强调对象职责行为的重要性，而这是对象和数据库唯一的区别，当然其上下文场景概念的提出，也可以认为体现了对角色和场景的重视，但远远不够。
相反，对象设计：角色、责任和协作"(Object Design: Roles, Responsibilities, and Collaborations))一书提出职责驱动开发，将对象行为上升为重点，提出了对象其实是在扮演某种角色，而角色是有职责的，然后会在一定场景上下文环境中实施一定交互行为，这些已经在Jdon进行了充分讨论：
DCI,领域模型，领域事件的一些想法
异步架构思维:使用Akka实现领域建模
该书总结了集中式控制器4大缺点，MVC的控制器实际就属于这种集中式控制器风格：
1.Control logic can get overly complex. 控制器会变得复杂，很多人在Struts的Action控制器中写业务代码已经变得很常见，所有的操作都在action中，有的action都几乎上千行了.
2.Controllers can become dependent on information holders' contents.控制器变得依赖信息数据中心或数据库了，控制器做很多事情，意味着领域对象就做很少事情，控制器最后不是只会做什么，决定战略性的事情，也和怎么做，如何实现等战术问题耦合。
3.Objects can become coupled indirectly through the actions of their controller. 对象将间接地通过控制器的action耦合在一起，一个对象在控制器中查询获得，然后复制给另外一个对象，这两个对象就耦合在一起。
4.The only interesting work is done in the controller.唯一有趣的工作是做控制器，Responsibilities职责被吸进控制器对象，只将一些行为留给角色模型完成，重要的事情都集中在控制器中了。
MVC的控制器是Mediator模式一种，也属于一种集中式控制器，它与观察者模式重大区别是：Mediator模式封装了通讯，而Observer分散通讯，从通讯角度来看，控制器也有其固有的缺陷，容易变成大而全高度耦合的集中器，这些都是为OO所不容。
DCI架构是最近才兴起的新概念，它从一个全新角度来看待软件，与职责驱动设计不谋而合，同时也是对DDD的发展和完善。
DCI是数据Data 场景Context 交互Interactions的简称，它重要贡献是提出了场景这个概念，而这点是职责驱动开发一书没有提及，该书只是否定了MVC,揭露其问题，没有提出替代方案，而DCI正是MVC的替代架构，DCI替代MVC 用场景替代控制器应该是大势所趋，如下图(图来自原文英文The DCI Architecture: A New Vision of Object-Oriented Programming)：
场景其实将MVC中Control和模型中一部分挖了出来，以角色场景方式进行重新组合。这是一种与MVC模式考虑角度完全不一样的新角度，这种角度更符合OO。
最近，有人提出 场景Context是新的对象类型，场景不但可以替代SOA的Web服务，也可以替代MVC的控制器。
个人认为：未来新的分层架构可能变成这样：
View --> Context ---> Domain Model ---> Component/Respository
MVC模式已死。