第五节 探索领域架构
一、领域驱动设计的价值与意义
最初在java中使用，.net要晚些才引入。领域驱动设计出现之初的争议。一个向导，少走弯路
1. 我们真的需要DDD吗？
DDD并不适用于每个软件项目，因为他需要掌握一相技能，可有较高的启动成本。也不会因为一个项目简单而阻止你使用DDD，在是否DDD方面有两误区，你觉得使用他很cool，你觉得项目只有稍复杂的CRUD。使用DDD的真正价值在于理如何时解决它并合理利用它
- 使用DDD分析
DDD 的分析部分包括两个相关元素: 通用的语言和边界上下文。
- 战略模型设计 Strategic model design
可以称DDD为面向领域模型的分层设计。模型可以是对象模板，也可以是或函数方法的集合。数据的持久性也依赖于模型，它可能是ORM工具映射出来的一组对象集合，也可能是由组件封装的存储过程调用获得。
二、通用语言
软件为业务而诞生，但是软件架构师不业务领域的专家，同样，业务领域的专家也可能不懂得软件设计。开发人员和领域专家对同一样单词可对被理解为不同意义。
1. 通用语言结构
2. 如何定义通用语言
通用语言是项目的官语言，贯穿于整个项目，coding、testing、document，它应该经过领域专业认可审核。可能表示为一组excel说明的短语，也可能是UML中的图表
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指代码层面物理层。
四、分层架构
简单三层架构数据模型受限于数据存储，随着项目复杂度增长，单一的数据模式不能满足多种意义上的概念视图，所以面向领域设计应运而生。
1. Presentation layer
展现层的职责是提供用户UI来完成交互任务。通常来说，用与展现给用户的数据称之为View model，用户完成输入后将数据传送到后台，这类数据称之为input model，大多情况上这两类模式是一致的，可以用一个模型来表示。
2. Application layer
包含了系统中的所有业务逻辑代码，应用层的职责是向展现层提供数据，并且要可以承载未来的需求变化。应用层是实现用例的地方。
3. Domain layer
领域层承载整个业务，并不针对某个用例，换句说领域层包含了所有在应用层上编辑实现的业务逻辑。领域层由域模板和和一系列服务组成。域模板的性质可以是多样的，通常情况下是一组实体映射模型，当然也可以包含函数。
4. Infrastructure layer
基础设施层是一切具体技术的使用，包括数据持久性 (O/RM 像实体框架的框架)、 特定安全 API、 日志记录、 跟踪，IOC容器，缓存等等。
第6章 表示层 presentation
一、用例体验第一(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 | |
Wirify |
二、真实应用场景
展现层主要包含两个组件：用户接口和展现层逻辑。用户接口为用户提供一个系统使用工具。.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的功能。
