facade

一、创建型模式 深入理解设计模式（一）：单例模式 (Singleton pattern): 确保一个类只有一个实例, 并提供全局访问点. 深入理解设计模式（二）：简单工厂模式 (factory method pattern): 实质是由一个工厂类根据传入的参数，动态决定应该创建哪一个产品类（这些产品类继承自一个父类或接口）的实例。 深入理解设计模式（四）：工厂方法模式 (factory method pattern): 定义了一个创建对象的接口, 但由子类决定要实例化的类是哪一个. 工厂方法让类把实例化推迟到子类 深入理解设计模式（五）：抽象工厂模式 (Abstract factory pattern): 提供一个接口, 用于创建相关或依赖对象的家族, 而不需要指定具体类. 深入理解设计模式（六）：原型模式 (prototype pattern): 当创建给定类的实例过程很昂贵或很复杂时, 就使用原形模式. 深入理解设计模式（七）：建造者模式 (Builder pattern): 使用生成器模式封装一个产品的构造过程, 并允许按步骤构造. 将一个复杂对象的构建与它的表示分离, 使得同样的构建过程可以创建不同的表示 二、行为型模式 深入理解设计模式（三）：策略模式 (strategy pattern) : 定义了算法族, 分别封闭起来, 让它们之间可以互相替换,

基于DDD的微服务设计和开发实战 目录 基于DDD的微服务设计和开发实战 1 目标 2 适用范围 3 DDD 分层架构视图 展现层 应用层 领域层 基础层 4 服务视图 微服务内的服务视图 1、接口服务 2、应用服务 3、领域服务 4、基础服务 微服务外的服务视图 1. 前端应用与微服务 2. 微服务与外部应用 5 数据视图 6 领域事件和事件总线 微服务内的领域事件 微服务之间的领域事件 事件总线 事件数据持久化 7 微服务设计方法 事件风暴 1、产品愿景 2、场景分析 3、领域建模 4、微服务拆分和设计 领域对象及服务矩阵和代码模型设计 1、领域对象及服务矩阵 2、微服务代码模型 领域对象及服务矩阵样例说明 8 微服务代码结构模型 微服务代码总目录 用户接口层代码模型 应用层代码模型 领域层代码模型 基础层代码模型 微服务总目录结构 9 微服务设计原则 第一条：“要领域驱动设计，而不是数据驱动设计，也不是界面驱动设计”。 第二条：“要边界清晰的微服务，而不是泥球小单体”。 第三条：“要职能清晰的分层，而不是什么都放的大箩筐”。 第四条：“要做自己能 hold 住的微服务，而不是过度拆分的微服务” 10 不同场景的微服务设计 新建系统的微服务设计 1、简单领域的建模 2、复杂领域的建模 单体遗留系统的微服务设计 特别说明 11 基于 DDD 的微服务设计和开发实例 项目基本信息

一、引言 在软件开发过程中，客户端程序经常会与复杂系统的内部子系统进行耦合，从而导致客户端程序随着子系统的变化而变化，然而为了将复杂系统的内部子系统与客户端之间的依赖解耦，从而就有了外观模式，也称作 ”门面“模式。下面就具体介绍下外观模式。 二、外观模式的详细介绍 2.1定义 外观模式提供了一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让子系统更容易使用。使用外观模式时，我们创建了一个统一的类，用来包装子系统中一个或多个复杂的类，客户端可以直接通过外观类来调用内部子系统中方法，从而外观模式让客户和子系统之间避免了紧耦合。 2.2 外观模式的结构图 介绍了外观模式的定义之后，让我们具体看看外观模式的由来以及实现，下面与学校中一个选课系统为例来解释外观模式，例如在选课系统中，有注册课程子系统和通知子系统，在不使用外观模式的情况下，客户端必须同时保存注册课程子系统和通知子系统两个引用，如果后期这两个子系统发生改变时，此时客户端的调用代码也要随之改变，这样就没有很好的可扩展性，下面看看不使用外观模式下选课系统的实现方式和客户端调用代码： /// <summary> /// 不使用外观模式的情况 /// 此时客户端与三个子系统都发送了耦合，使得客户端程序依赖与子系统 /// 为了解决这样的问题，我们可以使用外观模式来为所有子系统设计一个统一的接口 ///

Façade是一个法语词，意思是外观、门面，因此该模式又称为 外观模式 ！ 门面模式不仅仅是一种设计模式那么简单，更是一种设计素养，需要有边界划分的意识！ 动机(Motivation) 客户和组件中各种复杂的子系统有过多的耦合 如何简化外部客户程序和系统间的交互接口？如何解耦？ 模式定义 为子系统中的一组接口提供一个一致(稳定)的界面，Façade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用(复用)。 ——《设计模式》GoF 要点总结 从客户程序角度来看，Façade模式简化了整个组件系统的接口，对于组件内部与外部的客户程序来说， 达到了一种”解耦“的效果——内部子系统的任何变化不会影响到Façade接口的变化。 Façade设计模式更注重架构的层次去看整个系统，而不是单个类的层次。Façade很多时候是一种架构设计模式。 Façade设计模式并非一个集装箱，可以任意地放进任何多个对象。Façade模式组件中的内部应该是”相互耦合关系比较大的一系列组件“，而不是一个简单的功能集合。 结构（Structure） 基本代码 #include <iostream> using namespace std; class SubSystemOne { public : void MethodOne() { cout << " SubSystemOne " << endl; }

医院的例子 现代的软件系统都是比较复杂的，设计师处理复杂系统的一个常见方法便是将其"分而治之"，把一个系统划分为几个较小的子系统。如果把医院作为一个子系统，按照部门职能，这个系统可以划分为挂号、门诊、划价、化验、收费、取药等。看病的病人要与这些部门打交道，就如同一个子系统的客户端与一个子系统的各个类打交道一样，不是一件容易的事情。 首先病人必须先挂号，然后门诊。如果医生要求化验，病人必须首先划价，然后缴费，才可以到化验部门做化验。化验后再回到门诊室。 上图描述的是病人在医院里的体验，图中的方框代表医院。 解决这种不便的方法便是引进门面模式，医院可以设置一个接待员的位置，由接待员负责代为挂号、划价、缴费、取药等。这个接待员就是门面模式的体现，病人只接触接待员，由接待员与各个部门打交道。 门面模式的结构 门面模式没有一个一般化的类图描述，最好的描述方法实际上就是以一个例子说明。 由于门面模式的结构图过于抽象，因此把它稍稍具体点。假设子系统内有三个模块，分别是ModuleA、ModuleB和ModuleC，它们分别有一个示例方法，那么此时示例的整体结构图如下： 在这个对象图中，出现了两个角色： 门面(Facade)角色 ： 客户端可以调用这个角色的方法。此角色知晓相关的（一个或者多个）子系统的功能和责任。在正常情况下，本角色会将所有从客户端发来的请求委派到相应的子系统去。 子系统

ThinkPHP6.0的安装，官方文档中有详细的说明，不过在安装之前，大家还是要做一些准备的，就是PHP本地开发环境 的搭建。 官方手册地址： https://www.kancloud.cn/manual/thinkphp6_0/1037609 本地PHP环境的搭建 PHP本地开发环境的搭建 composer的安装和使用 学习PHP大家一定要对 composer 有所了解，至少使使用简单的命令。在使用时，注意更换源（国内镜像）。 ThinkPHP6.0的安装 如果你是第一次安装的话，在命令行下面，切换到你的WEB根目录下面并执行下面的命令： composer create -project topthink /think tp 这里的 tp 目录名你可以任意更改，这个目录就是我们后面会经常提到的应用根目录。 如果你之前已经安装过，那么切换到你的应用根目录下面，然后执行下面的命令进行更新： composer update topthink /framework 更新操作会删除 thinkphp 目录重新下载安装新版本，但不会影响 app 目录，因此不要在核心框架目录添加任何应用代码和类库。 一般情况下， composer 安装的是最新的稳定版本，不一定是最新版本，如果你需要安装实时更新的版本（适合学习过程），可以安装 6.0.x-dev 版本。 composer create

天佑武汉，天佑中国。这次为全国人民作出巨大牺牲的武汉人是坚强和担当的。 　　这次疫情期间的自我隔离的一个副作用是第一次享受这个超长假期，本来想好好学习一下Web技术的，但家里的唯一一台计算机被占用，不得已只能停下脚步，继续研究一下这个开源项目的领域模型。 　　搅拌站的生产管理事是以短期计划为核心展开的，每天生产调度人员根据工地的需求制定针对创建一个“日计划”。实验室人员会为这个日计划创建生产配方。日计划的生产不是连续性的，他会分解成很多小的批次计划。分解批次计划的原因是因为混凝土的交付有很多步骤组成，首先由搅拌站生产，再由搅拌车运输到工地，最后由混凝土泵车泵送到指定的浇筑位置。根据这个生产流程，我们很容易设计出模型的最初版本 　　 　　 再实际生产过程中，针对一些特殊的情况，批次计划会增加一些附加的动作，常见的有，每天第一批次是会额外生产一盘的砂浆（用于泵车输送管的润滑），如果是工地第一次开盘，还要打印质保书。这样在批次计划前应该增加一个批次计划报的对象来包含这些额外的动作。 　　 　　 如果仔细分析以上对象，不管是生产计划还是附加动作或者交付动作，他们都可以被执行或放弃，都需要跟踪执行的结果，本质上都是一个可以被执行的动作对象。并且可以根据动作执行的不同结果（如因为车辆问题，混凝土没有送到工地）可以启动一些补偿或后续动作。再这里我们可以引入动作模式（Martin Fowler

验证器 By:Mirror王宇阳 验证器定义 验证器的使用，必须定义它；系统提供了一条命令直接生产一个验证器类： php think make:validate User 自动再应用目录下生成一个 validate 文件夹，并生成 User.php 类 namespace app\validate; use think\Validate; class User extends Validate { /** * 定义验证规则 * 格式：'字段名' => ['规则1','规则2'...] * '字段名' => '规则1|规则2...' * * @var array */ protected $rule = [ 'name' => 'require|max:20', 'price' => 'number|between:1,100', 'email' => 'email' ]; /** * 定义错误信息 * 格式：'字段名.规则名' => '错误信息' * * @var array */ protected $message = [ 'name.require' => '姓名不得为空', 'name.max' => '姓名不得大于20位', 'price.number' => '价格必须是数字', 'price.between' => '价格位于1~100之间', 'email' =>

验证器 By:Mirror王宇阳 验证器定义 验证器的使用，必须定义它；系统提供了一条命令直接生产一个验证器类： php think make:validate User 自动再应用目录下生成一个 validate 文件夹，并生成 User.php 类 namespace app\validate; use think\Validate; class User extends Validate { /** * 定义验证规则 * 格式：'字段名' => ['规则1','规则2'...] * '字段名' => '规则1|规则2...' * * @var array */ protected $rule = [ 'name' => 'require|max:20', 'price' => 'number|between:1,100', 'email' => 'email' ]; /** * 定义错误信息 * 格式：'字段名.规则名' => '错误信息' * * @var array */ protected $message = [ 'name.require' => '姓名不得为空', 'name.max' => '姓名不得大于20位', 'price.number' => '价格必须是数字', 'price.between' => '价格位于1~100之间', 'email' =>

【今日推荐】：为什么一到面试就懵逼！>>> 基本介绍 外观模式（Facade Pattern）：外部与一个子系统的通信必须通过一个统一的外观对象进行， 它为子系统中的一组接口提供一个统一的高层接口，使子系统更容易被使用 。 外观模式又称为门面模式，它是一种对象结构型模式。 模式结构 1、Client（客户端）：调用者 2、Facade（外观类）：即上述所讲的高层接口 3、SubSystem（子系统）：被调用者 举例说明 想要使用电脑，你只需要按一下开机键（客户端），电脑的各个部件（子系统）就开始工作了，你不需要关心硬盘如何启动的，CPU怎么运转的等等，一切都交给内部程序（外观类）处理。 编写简单的程序模拟一下 「SubSystem」 ：电脑的几个部件 CPU、内存、硬盘 public class Cpu { //使用「单例模式--饿汉式」创建对象 private static Cpu instance = new Cpu(); private Cpu() { } public static Cpu getInstance() { return instance; } public void start() { System.out.println("CPU启动"); } public void stop() { System.out.println("CPU停止工作"); } }