代码改变世界

.NET 应用架构指导 V2 学习笔记(三) 软件架构的模式和风格

2010-05-22 07:23  Virus-BeautyCode  阅读(2100)  评论(3编辑  收藏  举报

  组件为基础的架构风格

  组建为基础的架构描述了一种设计和开发软件系统的软件工程方法。主要集中在将系统划分为单个功能或者是逻辑的组件,组件定义好用来通信的方法、事件和属性。相比面向对象设计原则来说,提供了更高层的抽象,不主要考虑通信协议和状态共享。

  组件为基础的风格的关键点是组件的使用:

  •   可重用,通常会将组件设计为在不同的应用、不同的方案中都可以使用。但是,也会设计一些专用的组件。
  •   可替代性,组件可以被其他相似的组件替代。
  •   不指定上下文环境,组件设计为需要在不同的环境和上下文进行操作。特殊的信息,例如数据状态,应该传递给组件,而不是被包括在组件内,或者被组件访问。
  •   可扩展性,一个组件应该可以从现有的组件扩展,提供新的行为。
  •   封装性,调用者通过组件提供的接口使用组件提供的功能,不能获取任何的内部实现细节和状态。
  •   独立性,组件被设计为相对其他组件的依赖性最小。因此组件可以部署在任何合适的环境,不影响其他组件和系统。

  在应用中常用的组件类型包括用户接口组件,例如grid和button,通常叫做控件,帮助和工具组件,提供一些供其他组件使用的功能。

  组件为基础的架构风格的好处包括:

  容易部署,组件版本更新的话,对于其他组件和系统没有影响。

  减少成本,使用第三方的组件允许你分散开发和维护成本。

  容易开发,组件通过实现定义好的接口来提供功能,开发不影响现有的系统。

  可重用,可重用的组件意味着你可以将成本分散到若干个系统中。

  减轻技术复杂性,通过使用组件容器和服务减轻复杂性。组件服务包括组件激活、生命周期管理、方法队列、事件、和传输。

  设计模式中的依赖注入DI或者是Service Locator模式都可以用来管理组件之间的依赖关系,提供松散的耦合和可重用性。这些模式经常用来构建组件应用,这些组件会在多个应用中使用。

  在下面的情况之下,你可以考虑使用组件为基础的架构风格:

  •   如果你有合适的组件,或者可以从第三方获取合适的组件
  •   你的系统主要用来执行事务性的功能,很少输入数据,设置没有输入数据
  •   你需要使用另外的语言编写的组件
  •   你希望创建一个插件式的架构,希望很容易的替代和更新单个组件

  Domain Driven Design Architecture Style领域驱动的架构风格

  DDD是一种面向对象的方法,基于业务领域、元素、行为,和他们之间的关系来建立软件的设计方法。目的是使得软件系统真实再现业务领域,通过定义表达业务领域专家语言的业务模型。

  使用DDD,你必须对想要建模的业务领域有很好的理解,或者有丰富的业务知识。开发团队经常会和业务专家一起工作,一起建模。架构师、开发者、主要的领域专家具有不同的背景,在不同的环境使用不同的语言描述他们自己理解的目标,设计和需求。但是,使用DDD,整个团队一致使用一种集中于业务领域的语言,排除了任何的技术术语。

  软件的核心就是业务模型,作为这个共享的语言的直接项目,使得团队通过分析描述模型的语言快速的发现软件的缺口。一个通用语言的创立不仅仅是一个训练,在接受从领域专家来的信息,并且应用它。通常,开发团队的沟通问题不完全是对于领域模型的错误理解,也有领域语言本身的模糊性。DDD过程目标不仅仅是要实现语言本身,而且是要提高和重新定义领域语言。转而对于软件构建是有好处的,因为模型就是领域语言直接的描述的工程。

  为了帮助保持模型作为一个纯净的、有用的语言结构。你一定要在领域模型中实现大量的独立性和封装性。结果就是,基于DDD的系统会有很高的代价。同时,DDD也提供了很多的好处,例如:可维护性,它应该只被用于复杂的模型,模型和语言学处理在沟通的过程中提供了明显的好处。

  下面是使用DDD带来的好处:

  沟通,在开发团队内部使用领域模型和实体,使用通用的业务领域语言定义了用来沟通的业务知识和需求,排除了使用技术术语。

  扩展性。

  可测试性。

 

  未完待续。。。。。。。。。。。。。。。。。。。。

  P26