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 theircontroller. 對象將間接地通過控制器的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 NewVision of Object-Oriented Programming)：
場景其實將MVC中Control和模型中一部分挖了出來，以角色場景方式進行重新組合。這是一種與MVC模式考慮角度完全不一樣的新角度，這種角度更符合OO。
最近，有人提出 場景Context是新的對象類型，場景不但可以替代SOA的Web服務，也可以替代MVC的控制器。
個人認爲：未來新的分層架構可能變成這樣：
View --> Context ---> Domain Model ---> Component/Respository