DDD系列-建模设计全流程

和以往的开发模式不一样的是，DDD不是从用户需求开始的，DDD的起点是用户故事，值得一提的是，为了避免瀑布流模式的缺点，从用户故事到战术设计不是一条不可逆的路，相反，最好的模式应该是斡旋前进。

挖掘用户故事

挖掘用户故事必须包含产品团队，领域专家，研发团队共同参与，这里值得一提的是，领域专家这个角色的定义，这里是相关领域有资深经验的专家，比如

1）针对医疗行业，那么医生就是领域专家

2）针对教育行业，那么老师就是领域专家

但是，普遍存在的一个现象是，公司里并没有这些领域专家，往往PM承担了这个角色，这样在一定程度上也是可以的。但是还是建议每间隔一段时间邀请真正的领域专家来介绍一些这个领域的故事。

定义用户故事

用户故事属于问题空间的描述，用户故事描述公式为

公式： 作为什么人，我希望做什么，达到怎么样的一个目的。

例子：作为用户，我希望能够通过手机在线上和医生交流，从而更加便捷的清楚病情

复杂版

公式：合适的人（who），通过合适的渠道（channel），将合适的内容（what），在合适的时段（when），发送给合适的客户（whom），产生一定的效果和反馈（effect）

例子：复杂的一句话用户故事，甚至可以把模型建立出来。

电商运营人员 希望 对7天内没有回购的用户 在 周六晚上8点 的时候 通过 短信提醒 的方式 发送一张优惠券 并且希望用户回来再次购物并 评价购物体验

例子

这里列举一个电影票务系统的例子，假设我们并不知道票务系统长什么样子，那么我们（架构师）就去聆听另一方（领域专家或者产品经理）陈述我们的电影票务系统

这里的话术是用简单的公式： 作为什么人，我希望做什么，达到怎么样的一个目的。注意，中间一定要问答和讨论，最后形成一个图形表述的用户故事。

例如，这是一个电影票务系统的用户故事描述，这种图会作为架构师，产品经理，领域专家讨论之后的用户故事图形表达。

建立通用语言

先来看一个笑话：

一飞机在四川上空遇到故障，四川空管台问：“出了啥子问题？”

机上发出了求救信号：“MAYDAY！MAYDAY！”

空管回复：“没得问题就好。”

（四川话“没得”和“MAYDAY”发音差不多，“没得”就是没有，“MAYDAY”是国际通用的无线电求救信号）

这个笑话在平时的工作中非常常见，基本产品团队一套术语，研发团队一套术语，经常出现两个平行时空的对话。有的研发或者产品能发现这个问题，当讨

DDD系列-如何判断要不要使用DDD

如何判断要不要使用DDD

当我们介绍业务背景的时候，一定要足够复杂，才可能继续讨论DDD如何解决这种复杂度的。如果是一个掷骰子游戏，那肯定不会用DDD去实现，这种例子只帮你理解一些概念。

这里参考尤达老师的零售项目，整个背景可以用下面一张图表示

1）运营人员通过电脑操作投放售卖机

2）用户通过手机支付的方式购买商品

3）安装人员按照安装单到指定地点安装售卖机

4）商务会去各商场洽谈合作售卖机事宜

5）配送人员必须及时按照配送单补充售卖机商品

一个智能零售主要包含以上功能，注意，这里不包含细节，但是所有的角色都在里面，需要讨论每个细节的时候，会再次深入到内部。比如你需要考虑购买问题的时候，用户是使用微信，支付宝，或者硬币支付，或者小程序会员的方式进行购买，再或者，这里搞打折活动......

 以及同理，下面是一个简化的在线医院系统，目的是让用户足不出户即可达到看病的目的

这个系统也很复杂，模拟了一套线下看病的流程

1）用户在手机上输入足迹的病情，类似去医院对着窗口说自己感冒嗓子疼

2）助手，类似那个窗口给你挂号的，会告你去什么科室看病，这里直接是指派给一名医生了，简化了一下

3）医生，医生进行接诊操作，类似现实中你坐到了医生的对面，然后就行一些谈话

4）医生给你开局药品清淡，然后你进行线上支付，来购买药品

5）药品配送人员会将这些药品送到你的家门口

整个系统是极其复杂的，任何一个环节拿出来都可以构成一个小系统，比如开药的环节，就会引入处方药和非处方药等领域的概念，另外他们也需要处理监管的问题

总结，以上两种情况都非常适合使用DDD，理由是他们足够复杂，并且相应的现实世界已经有一套成熟的模型，软件开发人员必须亲自搞懂现实中的这些系统是如何运作的，它们的关系是怎样的，然后将这一套模型映射到我们的软件系统中。

我们通常说代码尽量不要复用，软件模型也是同样的道理，现实生活中有的模型尽量参考，改进，避免盲目创建出一个毫不相干的新模型。

DDD系列-聊聊敏捷开发模式的缺点

敏捷开发模式

在我以前的软件开发经验中，很多软件都是基于分层思想+贫血模式设计的（如下图），也许从入行开始就一直是这样，也并没有发现什么问题。

一句话总结以前的开发思路："表建好了，代码也就写好了"

敏捷研发流程

一般从需求开始（其实是局部的需求，RD往往没有全局信息），产品同学将需求分析完和开发同学进行需求评审，评审完毕后开发同学开始基于需求进行技术方案设计。这时候一般会落到数据库设计，将库表设计完毕。设计完表之后，我们常说的"Dao层"就有了，接下来就进行逐层向上开发，最后封装出一个api接口。

这时候你会发现真的是"表建好了，代码也就写好了"，数据驱动开发或者说是一种基于数据模型的开发。这种开发模型所有的业务逻辑都堆砌在Model层，其实可能开发者本身都没理解这一层的含义，因为Controller层不能直接穿透到Dao层，所以不得不在Model层继续傻瓜式封装一下dao层

敏捷研发最有价值的产出

由于敏捷开发基本是基于数据驱动开发的，所以它的设计基本就是敏捷需求开发的最有价值的输出了，例如客户下单的需求为例子

敏捷开发的舒适期

这种开发方式在创新项目的前期，非常适合用这种方式，因为首要任务是项目能够活下来，不要被淘汰掉。这种模式就非常适合低成本

快速迭代起来，并且新人这个时候是友好的，从api入口开代码能够一口气看下来，逻辑基本上就明了了。

敏捷开发的阵痛期

如果跨过了舒适期，来到阵痛期，恭喜你，至少项目活下来了。这个时间开发和迭代变得非常困难了，更有甚者，一张表的扩展字段可能达到恐怖的100多个了（笔者曾经所在的公司）。这个时候没有一个新人来了不骂娘的，因为根本不可能是正常人能理解的东西了。整个大项目来到一个大单体时代

1）大单体-拆表：治标不治本，只是解决容量问题，对业务的复杂度是没有贡献的

2）大单体-拆微服务（伪服务）：为什么说是伪微服务，把dao层暴露api接口作为一个一个服务，然后让大单体接入，后面介绍DDD会知道，这只是改变了调用方式，根本对减少业务复杂度没有任何贡献，反而因为网络请求增加了复杂度

3）大单体-拆微服务（局部拆分）：比如电商中的收件人作为微服务，然后包含了各种冲突，融合，关系等完善的服务。然后用这个新微服务潜入到大单体中。这也是死路一条，后面介绍DDD会知道，它改变了模型（虽然作者可能都不知道隐含的模型），模型的改变必然导致

DDD系列-背景

其实笔者认为，在软件的发展过程中，业务价值始终是排在第一位的，笔者之前所在的公司一直是敏捷开发模式，问题也基本上朝着单体应用的毛病一步一步演进，但是在期间也创造了大量的业务价值。在演进的过程中，会出现各种问题，更高级的开发模式往往能解决更多的问题，但是这并不大表越高级越好，适合当前业务的模式才是最好的开发模式。

瀑布流开发模式

模式介绍

软件设计有不同的方法，其中之一是瀑布设计法。这种方法包含了一些阶段，业务专家提出一堆需求同业务分析人员进行交流，分析人员基于那些需求来创建模型并将结果传递给开发人员，开发人员根据他们收到的内容开始编码。瀑布设计法中知识只有单一的流向。这种传统方法虽然应用很多年，但是还是有一定的缺陷和局限。主要是业务专家得不到分析人员的反馈信息，分析人员也得不到开发人员的反馈信息。

假设要做一个在线售卖机系统，那这个售卖机所有的用例集合起来称为需求，然后严格按照需求-设计-开发-测试一次性搞定。

有的人可能会有疑问，我们现在不就是这样开发的吗，注意，这里的需求不同于我们平时PM说的需求，PM层面的需求是一个一个用例，这里的需求是所有的用例集合。

整个过程可以用下图描述

主要缺点

这种方式的主要缺点是周期长，没有反馈闭环，项目失败的风险极高。而且，这种方式一开始就确定了所有需求，考虑面面俱到，但是这所有的需求中大部分的需求

都没有机会使用。这种方式的项目大部分以失败告终。

主要优点

但是，有一些场景必须用瀑布流开发模式，比如航天飞机，摩天大楼这些中途一旦变更需求，将会造成巨大的成本，所以肯定是需求阶段就已经面面俱到了。

敏捷开发模式

模式介绍

由于瀑布流开发模式失败率太高，另一个方法是敏捷方法学，这些方法不同于瀑布方法的一堆动作，产生背景是预先很难确定所有的需求，特别是需求经常变化的情况。敏捷开发试图解决另一个问题被称为"分析瘫痪"，团队成员会因为害怕做出任何设计决定而无济于事。敏捷开发者反对预先设计，相反，他们应用大量的灵活设计。在敏捷设计者的眼中，他们崇尚，天下武功，唯快不破。

还是用售卖机为例子，那这个售卖机中的一个支付支持作为一个需求，就仅仅这一个需求在敏捷者的眼里，也不会一次性开发完成，而是周期迭代方式进行。

敏捷开发的优点非常多，比如团队协作，项目风险控制，市场验证，非常适合创新项目，也是现在很多公司主流的开发模式

主要缺点

敏捷开发也有自己的不足，敏捷开发

GO语言设计模式 - 构建者模式

背景

假设我们需要实例化一个MySQL对象，在GO语言中，可以使用下面两种方式

逐个参数传递

func NewMySQL(a TypeA,b TypeB,c TypeC) MySQL

在GO语言中，函数是没有默认值的，这就意味着，假设NewMySQL函数有10个参数，所有的使用方必须传递满这是个参数，如果这勉强还能接受

那么，假设不值10个参数，后果可想而知。可以说这种办法几乎不可取，函数签名随着参数的个数变化不断变化

结构体传递

Type Params{
    a TypeA
    b TypeB
    c TypeC
}
func NewMySQL(p Params) MySQL

这种方式比第一种好一点了，至少看起来是不用传递多个参数，函数签名也不用发生改变。这里我们把MySQL的实例化条件复杂一点，结构体层级化，看下使用方视角

opt := Params{
    Endpoint: {
        IP: "xxxx",
        Port: "xxx",
        ....
    },
    Timeout:{
        ReadTimeout: "xxx",
        WriteTimeout: "xxx",
        ConnectTimeout: "xxx",
        ....
    },
    ....
    //更多陌生的选项
}

obj := new NewMySQL(opt);

这种方式对使用者不友好，创建对象时需要知道的细节太多，其次，代码的可读性也差。当然还有一个更致命的缺点，默认值问题

在GO里面变量声明的时候就等于初始值（int是0，string是""，bool为false），举例：当接受到的参数为0时候，不确定是用户有意传递的0还是用户没有传递结构体变量导致的0，程序很难做出判断。

构建者模式

建造者（Builder）模式由产品、抽象建造者、具体建造者、指挥者等 4 个要素构成，现在我们来分析其基本结构和实现方法。

模式的结构

建造者（Builder）模式的主要角色如下。

1. 产品角色（Product）：它是包含多个组成部件的复杂对象，由具体建造者来创建其各个零部件。
2. 抽象建造者（Builder）：它是一个包含创建产品各个子部件的抽象方法的接口，通常还包含一个返回复杂产品的方法

GO语言设计模式-工厂模式

工厂模式背景

假设一个场景，在一个基本的MVC框架中，视图层承担着渲染数据的职责，假如要实现一个框架的视图层，必须满足

1. 支持html输出
2. 支持json格式输出
3. 支持xml格式输出
   于是，我们可以这样写出一个视图调用的展示程序View：

func render(typ string, data interface{}) {
	switch typ {
	case "json":
		bytedata, _ := json.Marshal(data)
		fmt.Println(string(bytedata))
	case "xml":
		bytedata, _ := xml.Marshal(data)
		fmt.Println(string(bytedata))
	//...继续延续其他类型
	default:
		panic("type err")
	}
}

这样做代码比较简单，但是，这样的实现存在很多问题。

1. 无法灵活地扩展和维护,如果再添加一个excel类型的输出，switch分支将变得老长老长
2. 修改任何一个功能，都需要改动主体代码块
   实际上，这是一种典型的面向过程的编码方式，这种编码方式，不易分工，职责不明确，如果采用面向对象的方式来救场，针对接口编程而不是针对实现编程。因为这样的视图层在我们的前辈也一样会碰到，只不过他们把这种问题解决掉了，留给了我们后人一些很经典的解决问题的设计模式。接下面，使用设计模式中的工厂模式解决这个问题

工厂模式分类

工厂模式主要是为创建对象提供了接口。工厂模式按照《Java与模式》中的提法分为三类：

1. 简单工厂模式(Simple Factory)
2. 工厂方法模式(Factory Method)
3. 抽象工厂模式(Abstract Factory)
   这三种模式从上到下逐步抽象，并且更具一般性。还有一种分类法，就是将简单工厂模式看为工厂方法模式的一种特例，两个归为一类。下面是使用工厂模式的两种情况：
   1.在编码时不能预见需要创建哪种类的实例。
   2.系统不应依赖于产品类实例如何被创建、组合和表达的细节

简单工厂模式

其实严格意义上来说，这并不算一种设计模式，或者可以说这是一种很好的封装方式。比如，可以解决我们上面的问题，我们可以做出以下优化

1. 为每个View的实现约定一个接口，这个接口定义每个子类必须实现特定的方法
2. 把变化的动画抽到一个地方，编写一个专门管理视

GO语言设计模式-单例模式

什么是单例模式

单例模式是一种常用的软件设计模式，其定义是单例对象的类只能允许一个实例存在。

许多时候整个系统只需要拥有一个的全局对象，这样有利于我们协调系统整体的行为。比如在数据库连接中，我们只希望进程内所有的访问DB都是通过一个数据库连接进行的。

普通实现-并发不work

单例模式第一种实现方式

// 单例模式
package design

import "fmt"

type singleton struct {
	Name string
}

var instance *singleton

func GetInstance() *singleton {
	if instance == nil {
		fmt.Println("init") //这里每实例化一次，输出init
		instance = &singleton{}
	}
	return instance
}

这种实现方式在没有并发的情况下是正常工作的

package main

import (
	"learn/design"
)

func main() {
	//串行执行正常
	design.GetInstance() //输出init
	design.GetInstance() //不输出init
}

但是一旦出现并发的情况，这种实现方式是就不能正常工作了

package main

import (
	"learn/design"
	"sync"
)

func main() {
	//并发不正常
	var wg sync.WaitGroup
	for i := 0; i < 10; i++ {
		wg.Add(1)
		go func() {
			defer wg.Done()
			design.GetInstance() //每一次，均输出init
		}()
	}
	wg.Wait()
}

once 方式实现-并发work

上面实现的第一种方式在并发情况下并不能正常work，这里使用once方式支持并发执行一次，一般比较常用的就是这种方式了

// 单例模式
package design

import (
	"fmt"
	"sync"
)

type singleton struct {
	Name string
}

var instance *singleton
va