.net架构设计读书笔记--第二章 设计体系结构

第五节 探索领域架构

1、领域驱动设计的价值与意义

最初在java中使用，.net要晚些才引入。领域驱动设计出现之初的争议。一个向导，少走弯路

 

1. 咱们真的须要DDD吗？

DDD并不适用于每一个软件项目，由于他须要掌握一相技能，可有较高的启动成本。也不会由于一个项目简单而阻止你使用DDD，在是否DDD方面有两误区，你以为使用他很cool，你以为项目只有稍复杂的CRUD。使用DDD的真正价值在于理如什么时候解决它并合理利用它

• 使用DDD分析

DDD 的分析部分包括两个相关元素: 通用的语言和边界上下文。

• 战略模型设计 Strategic model design

能够称DDD为面向领域模型的分层设计。模型能够是对象模板，也能够是或函数方法的集合。数据的持久性也依赖于模型，它多是ORM工具映射出来的一组对象集合，也多是由组件封装的存储过程调用得到。

 

2、通用语言

    软件为业务而诞生，可是软件架构师不业务领域的专家，一样，业务领域的专家也可能不懂得软件设计。开发人员和领域专家对同同样单词可对被理解为不一样意义。

1. 通用语言结构

2. 如何定义通用语言

通用语言是项目的官语言，贯穿于整个项目，coding、testing、document，它应该通过领域专业承认审核。可能表示为一组excel说明的短语，也多是UML中的图表

3. 保持语言和模型的同步

3、上下文边界

上下文边界是应用程序的一个区域，在这个区域里它有本身的通用语言，而且有本身的架构。

1. 定义上下文的边界

• 单一上下文边界要包含全部实体

• 不一样的上下文边界共享核心实体

 

• 不一样的上下文边界对通用实体作不一样的定义

 

 

2. 上下文关系映射

上下文的数据和边界上下文的关系每每是反映现实企业的物理组织架构，如人力资源、 会计、 销售、 库存、 等。 

Anticorruption layer (ACL) 防御层	一个扩展层用来隐藏上游上下文对下游上下文的影响
Conformist 被动服从	下游上下文无条件适应上流数据，不定下流是否须要数据
Customer/Supplier 生产者/消费者	上下游关系的两个经典关系模式，上游是生产者，下游是消费都，共同协做，确保不用数据不会实下游接收。这点不一样于上一条
Partnership	两个独立的上下文，不共享数据，均可以同时为上游或下游上下文。
Shared kernel	共享核心数据

    

3. Common supporting architectures 经常使用架构

Multilayer architecture	Canonical segmentation based on presentation, business, and data layers  The architecture might come in slightly different favors, such as an additional appli- cation layer between the presentation and business layers and with the business layer transformed into a domain layer by the use of a DDD development style  Layered architecture is just another name for a multilayer architecture  We'll be using the term layered architecture instead of multilayer in the rest of this chapter and throughout the book
Multitier architecture	Segmentation that is in many ways similar to that of a multilayer architecture   except that now multiple tiers are involved instead of layers  (More on the possible downsides of a layer-to-tier mapping in a moment )
Client/server architecture	Classic two-layer (or two-tier) architecture that consists only of presentation plus data access
Domain Model	Layered architecture based on a presentation layer, an application layer, a domain layer, and an infrastructure layer, designed in accordance with the DDD develop-ment style  In particular, the model is expected to be a special type of object model
Command-Query Respon Segregation (CQRS)	Two-fold layered architecture with parallel sections for handling command and query sides  Each section can be architected independently, even with a separate supporting architecture, whether that is DDD or client/server
Event sourcing	Layered architecture that is almost always inspired by a CQRS design that focuses its logic on events rather than plain data. Events are treated as frst-class data, and any other queryable information is inferred from stored events
Monolithic architecture	The context is a standalone application or service that exposes an API to the rest of the world  Typical examples are autonomous web services (for example, Web API host) and Windows services  Yet another example is an application hosting a SignalR engine

4。 Layers 和 tiers 的区别

Layers 指逻辑层，tiers指代码层面物理层。

 

4、分层架构

 

简单三层架构数据模型受限于数据存储，随着项目复杂度增加，单一的数据模式不能知足多种意义上的概念视图，因此面向领域设计应运而生。

1. Presentation layer

展示层的职责是提供用户UI来完成交互任务。一般来讲，用与展示给用户的数据称之为View model，用户完成输入后将数据传送到后台，这类数据称之为input model，大多状况上这两类模式是一致的，能够用一个模型来表示。

2. Application layer

包含了系统中的全部业务逻辑代码，应用层的职责是向展示层提供数据，而且要能够承载将来的需求变化。应用层是实现用例的地方。

3. Domain layer

领域层承载整个业务，并不针对某个用例，换句说领域层包含了全部在应用层上编辑实现的业务逻辑。领域层由域模板和和一系列服务组成。域模板的性质能够是多样的，一般状况下是一组实体映射模型，固然也能够包含函数。

4. Infrastructure layer

基础设施层是一切具体技术的使用，包括数据持久性 (O/RM 像实体框架的框架)、 特定安全 API、 日志记录、 跟踪，IOC容器，缓存等等。

 

 

第6章 表示层 presentation

 

1、用例体验第一(User experience frst)

软件开发的目的是让客户用他本身喜欢的方式有效的完成他本身的业务。任务软件存在都要产生结果，不管是屏幕、文件、或数据库更新。越了解预期的结果，能够越有效的掌控你的开发计划。

当预期的结果含有用户界面或用户交互，专一于用户交互引入 基于任务设计

1. 基于任务设计(Task-based design)

要一次性完成复杂的系统设计很困难，直接从模型开始设计不切合实际，轻量化的方法是从任务执行开始，每一个任务的输入、输出开始分析。使用UML设计用例是很好的选择。

• 为每一个用户界面提供一个model

    类没有多余的行为，只是作数据数据传输所用（DTO），用于在不一样分层之间传递数据。

2. 用户体验不是用户界面（UX is not UI）

• UX 专家的责任

UX专家也可称之为UX架构师、UX设计，是一个分析与设计并俱的角色。UX专家的任务是分析用户行为，而后为系统设计一个好的用户操做体验。UX设计的主要原则

  ■ Information architecture 信息体系架构

  ■ Interaction design  交互设计

  ■ Visual design 视觉设计

  ■ Usability reviews 可用性评估

• UX设计工具 Tools for UX experts

Axure	http://www.axure.com
Balsamiq	http://balsamiq.com
UXPin	http://uxpin.com
Wirify	http://www.wirify.com

2、真实应用场景

展示层主要包含两个组件：用户接口和展示层逻辑。用户接口为用户提供一个系统使用工具。.net框架下展示层应用包括web和wpf,winform。web下主要为asp.net站点。

1. Asp.Net网站

典型的asp.net网站中展示层补分为浏览器端和web服务端。用户接口使用html在浏览器上呈现给客户，逻辑部分由IIS等服务端承载。asp.net mvc和webform对表示层两种不一样方式的实现。

• Application Services

在asp.net应用程序中，应用层被设计为controller, 在内部咱们也将application-layer称之为worker services，如今咱们趋向于将worker services称之为DDD中的application services.

如上图解：决方案中的HomeController与HomeServices关联。一个HomeServices实例经过IOC容器或人为注入到HomeController中。

这个项目中中，application layer用解决方案的一个Services文件夹表示。能够将Services移出到一个独立的层，用宿主程序来承载，包装公开为终结点。（能使用web api的就不要使用wcf, 微软在web api和signalR上投入不少，推荐使用）

Application service类的方法与用例一一对应，每一个方法都实现一个必要的流程，由input mode开始，返回view mode。大多状况下controller的逻辑可简单为以下的Index方法。

public class HomeController 

{ 

    private readonly IHomeService _service; 

    public HomeController(IHomeService service) 

    { 

       _service = service; 

    } 

 

    public ActionResult Index() 

    { 

       var model = _service.FillHomePage( /* input model */ ); 

       return View(model); 

    } 

    ... 

}

Application Services有访问全部底层应用的权限，能够查询、更新数据，若是有须要能够扩展为web services。若是有demain model, application services应该要有权限将这些实现转为view model的功能。