组件为基础的架构风格
组建为基础的架构描述了一种设计和开发软件系统的软件工程方法。主要集中在将系统划分为单个功能或者是逻辑的组件，组件定义好用来通信的方法、事件和属性。相比面向对象设计原则来说，提供了更高层的抽象，不主要考虑通信协议和状态共享。
组件为基础的风格的关键点是组件的使用：
- 可重用，通常会将组件设计为在不同的应用、不同的方案中都可以使用。但是，也会设计一些专用的组件。
- 可替代性，组件可以被其他相似的组件替代。
- 不指定上下文环境，组件设计为需要在不同的环境和上下文进行操作。特殊的信息，例如数据状态，应该传递给组件，而不是被包括在组件内，或者被组件访问。
- 可扩展性，一个组件应该可以从现有的组件扩展，提供新的行为。
- 封装性，调用者通过组件提供的接口使用组件提供的功能，不能获取任何的内部实现细节和状态。
- 独立性，组件被设计为相对其他组件的依赖性最小。因此组件可以部署在任何合适的环境，不影响其他组件和系统。
在应用中常用的组件类型包括用户接口组件，例如grid和button，通常叫做控件，帮助和工具组件，提供一些供其他组件使用的功能。
组件为基础的架构风格的好处包括：
容易部署，组件版本更新的话，对于其他组件和系统没有影响。
减少成本，使用第三方的组件允许你分散开发和维护成本。
容易开发，组件通过实现定义好的接口来提供功能，开发不影响现有的系统。
可重用，可重用的组件意味着你可以将成本分散到若干个系统中。
减轻技术复杂性，通过使用组件容器和服务减轻复杂性。组件服务包括组件激活、生命周期管理、方法队列、事件、和传输。
设计模式中的依赖注入DI或者是Service Locator模式都可以用来管理组件之间的依赖关系，提供松散的耦合和可重用性。这些模式经常用来构建组件应用，这些组件会在多个应用中使用。
在下面的情况之下，你可以考虑使用组件为基础的架构风格：
- 如果你有合适的组件，或者可以从第三方获取合适的组件
- 你的系统主要用来执行事务性的功能，很少输入数据，设置没有输入数据
- 你需要使用另外的语言编写的组件
- 你希望创建一个插件式的架构，希望很容易的替代和更新单个组件
Domain Driven Design Architecture Style领域驱动的架构风格
DDD是一种面向对象的方法，基于业务领域、元素、行为，和他们之间的关系来建立软件的设计方法。目的是使得软件系统真实再现业务领域，通过定义表达业务领域专家语言的业务模型。
使用DDD，你必须对想要建模的业务领域有很好的理解，或者有丰富的业务知识。开发团队经常会和业务专家一起工作，一起建模。架构师、开发者、主要的领域专家具有不同的背景，在不同的环境使用不同的语言描述他们自己理解的目标，设计和需求。但是，使用DDD，整个团队一致使用一种集中于业务领域的语言，排除了任何的技术术语。
软件的核心就是业务模型，作为这个共享的语言的直接项目，使得团队通过分析描述模型的语言快速的发现软件的缺口。一个通用语言的创立不仅仅是一个训练，在接受从领域专家来的信息，并且应用它。通常，开发团队的沟通问题不完全是对于领域模型的错误理解，也有领域语言本身的模糊性。DDD过程目标不仅仅是要实现语言本身，而且是要提高和重新定义领域语言。转而对于软件构建是有好处的，因为模型就是领域语言直接的描述的工程。
为了帮助保持模型作为一个纯净的、有用的语言结构。你一定要在领域模型中实现大量的独立性和封装性。结果就是，基于DDD的系统会有很高的代价。同时，DDD也提供了很多的好处，例如：可维护性，它应该只被用于复杂的模型，模型和语言学处理在沟通的过程中提供了明显的好处。
下面是使用DDD带来的好处：
沟通，在开发团队内部使用领域模型和实体，使用通用的业务领域语言定义了用来沟通的业务知识和需求，排除了使用技术术语。
扩展性。
可测试性。