Archive for 七月, 2013

TODO

1. 架构

2. 网络交互lib库支持

3. 核心业务封装

“架构的核心是目的,而我们却把它变成了框架和细节”,Robert C. Martin(又名“Bob大叔”)在今年伦敦举办的DDD Exchange Day大会

Robert引用了Growing Object-Oriented Software Guided by Tests一书中描述的架构模型(类似于Hexagonal架构),该模型通过三大块描述架构,这三块之间形成单方向的依赖关系——更易变的部分依赖于更稳定的部分:

  • 域模型,其中包含业务规则,它是最稳定且最重要的业务部分,不依赖于任何其他部分。
  • 应用服务,它实现了系统的用例,它使用并依赖于域模型。
  • 外部细节、数据库、用户接口、网络等,它们与业务模型的关系更少,是最易变的部分,依赖于其他两块。

Robert指出,这一模型无法描述他所谓的关键内容:架构在于目的,即应用程序到底做什么。他认为,我们太过关注细节和框架,以致于使它们变成了系统的中心。

为解决这一短板,Robert带我们回顾了Ivar Jacobson于1992年编著的一本书,”Object-Oriented Software Engineering, A Use Case Driven Approach“。Ivar在此书中定义了一个应用架构,它基于许多小型用例,而用例不含细节。 Ivar引入了三类对象,它们能自然地适应架构模型。Rovert对它们的描述如下:

  • 交互者(Interactor)理解用例并包含针对特定应用的业务规则。
  • 交互者使用带有业务规则的实体(Entity)。
  • 边界(Boundary)对象在外部世界与交互者之间转移数据。

Robert认为该模型的一个重要的优势是,它是一个可测试的模型,无需依赖于任何基础设施就可以对它进行测试,只需通过边界对象发送和接收对应的数据结构即可。

接着,Robert转而介绍他的Clean架构模型,它是前述架构的一个变体。以上三个模型有一个共同核心,即它们都遵循稳定依赖原则,不对变化或易于变化的事物形成依赖。为实现了这一原则,上述模型让外部易变的部分依赖于更加稳定的部分,如域模型,而非形成相反的依赖关系。这样还可使实现变得更易于变化;多变的部分依赖于稳定的部分,Robert说:

好架构就要能轻松地改变那些易变的决定。

Robert还引用了Jim Coplien及其DCI架构,他认为这也相似的架构。

针对Robert近些年提出的架构思想,人们提出了一些批评意见,Robert也作出了回应


查看英文原文:Uncle Bob: Architecture is About Intent, not Frameworks

————————————

现在我的架构比较单一,被我所见过的web应用所局限。不过从来不相信有一种架构模型能够放之四海而皆准。学习大师们的架构,融为自己的,才是正道。当然,这里的架构都指较大范围的系统架构,区别于代码层面的架构。

http://alistair.cockburn.us/Hexagonal+architecture

http://en.wikipedia.org/wiki/Package_Principles

http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html