建立函数模型的步骤和方法 数学建模的步骤过程

领域模型=代码如果说敏捷应用研究主张面对面沟通交流，通过超快迭代的手段，让有价值的应用尽早面向市场，从而适应超快变化的要求。

那么DDD则为敏捷研究过程中的沟通交流形式，作出了进一步的补充。纵观DDD的所有环节，无一不是在打通领域专家和研究人员之间的沟通交流和交流。DDD的精髓在于通过让研究人员理解领域，进而让研究人员使用编程语言建立一个跟领域专家脑海中一致的领域模型，使得该领域模型成为各位共享知识的途径，这将有效的减少不同利益相关者的沟通交流及交流，确保所有人都在解决同一个问题。

共享模型=代码=文档我还清晰的记得我的第一份工作，每当有代码或者设计改动时，都要去更新UML类图以及数据库设计文档。这些文档大概充当着共享模型的作用，但是最终这些设计类图和文档都长久以来变得不可信，因为没有任何手段保证文档会被及时跟新。

说实话代码比较擅长表示设计内容，从本质上讲，源代码是一个文档，可以完美地描述产品的每个目前设计决策。

原则上，如果研究人员用代码创建了一个领域专家脑海中一致的领域模型，则代码无疑是最有效，最实时的共享模型。

唯一制约这个等式的鸿沟在于领域专家能否读懂代码。而简单易学，有表示力，直观的编程语言则能在创建领域模型的过程中占领一些优势。

领域建模领域建模是整个DDD环节中最最考验研究人员功底的一环，不同于经典的数据库建模技术，研究人员需要有很好的抽象能力，通过恰如其分的编程技术，将领域知识映射到一个代码模型中。

长期以来OO语言被认为是领域建模的首选，一些OO的技术可以很好的用来抽象领域模型。而函数式语言则被普遍认为只能用来做数据处理，科学计算等。本文将为各位展示如何通过函数式编程语言进行领域建模，本文选用TypeScript编写实例，TypeScript类型系统完全满足函数式编程要求，当然本文也适合用于其他拥有静态类型系统并拥有代数数据类型的函数式编程语言。

TypeScript的类型系统相对于OO，你只要知道少量的语法知识就可以开始领域建模了，从这个角度来讲，说实话代数数据类型更适合领域建模，从而让领域模型成为文档。

类型各类编程语言在设计的时候就已经提供了差不多string, bool, number等简单类型(primitive)，然而在真实世界里面，你还需要将这些类型组合成更大的类型，从而来映射现实世界。

在TypeScript中，type关键字用来组合更大的类型:

type Name = {  firstName: string  middleName: string  lastName: string}上面类型的用途是明显可以看见的，除此之外type还有起别名的用途，不要小瞧这个特性，他可以帮助你把领域知识记载在你的领域模型中，考虑下面的代码：

const timeToFly = 10

你能一眼看出这句代码代表的领域知识吗？也许不能，fly多久？查文档？No，你应该时刻告诉自己，代码等于文档。改进后的代码如下：

type Second = numberconst timeToFly: Second = 10Or类型在TypeScript，这种类型被称为联合（Union Types)，通过符号|来创建，考虑下面的类型:

type Pet = Fish | Bird

Pet是Fish或者是Bird类型。一般来探讨函数式语言都会有强大的模式匹配能力，来处理这种或类型，然而受制于TypesScript没有模式匹配或者说能力很弱，通常情况下，会在类型里面添加一个字符串字面量, 从而来区分不同的类型, 在次不再细说。

And类型在Typescript中，这种类型被称为交叉类型(Intersection Types)，通过符号&来创建，考虑下面的类型：

type ABC = A & B & C

表示ABC类型包含所有A、B、C三个类型里面的属性。

定义函数类型在TypeScript中，函数与其他类型没什么区别，也完全可以通过type关键字来定义，例如：

type Add = (a: number) => (b: number) => number

Add是一个函数，接收两个类型为number的类型a和b，返回number。

通过代码来共享领域知识type CreditCard = {  cardNo: string  firstName: string  middleName: string  lastName: string  contactEmail: Email  contactPhone: Phone}通过前面介绍的知识，咱们非常的容易就可以写出上面的代码，用来描述CreditCard这种付款选项。注意咱们没有使用class。

但这就是一个靠谱的领域模型吗？如果不怎么靠谱，它的问题在哪里？

这段代码最大的问题是他没有把本该拥有的领域知识记录在其中，我来试着问你几个问题：

问：middle name可以为空吗？答1：不清楚，也许需要查文档。答2：也许可以吧？middle name可以为null。

为可空类型建模在函数式编程语言中，可空类型被定义为Option，虽然null在ts中是合法的（注：咱们可以通过strictNullChecks来强致null检查)，但是在函数式编程语言中，你只能通过Option类型来表示可空类型。

当领域专家告诉你middle name可以存在，或者为空。注意用词“或”，说明咱们可以通过Union类型来为可空类型建模。

type Option</t><t> = T | null

一个简单的Option其实就是一个或类型, 当然你可以使用一个更加复杂的Option实现, 不过不在咱们今天的讨论范围内。经过改写后的代码变成了这样：

type CreditCard = {  cardNo: string  firstName: string  middleName: Option<string>  lastName: string  contactEmail: Email  contactPhone: Phone}避免基本类型偏执(Primitive Obsession)问：cardNo可以用string来表示吗？如果是，它可以是任意字符串吗？firstName可以是任意长度的字符串吗？很显然，你无法回答上面的问题，源于这个模型并没有包含有此类领域知识。

也许在编程语言里面，cardNo可以用string表示，但是cardNo在领域模型中，string无法表示出cardNo的领域知识。

cardNo是一个200打头的19位字符串，name是一个不超过50位的字符串，这样的领域信息可以通过type alias来实现：

type CardNo = stringtype Name50 = string...有了上面两个类型，你就有机会通过定义函数的方式，将cardNo业务规则包含在领域模型中。

type GetCardNo = (cardNo: string) => CardNo

如果客户输入了一个20位的字符串，函数GetCardNo返回什么？null？抛出异常？说实话函数式编程语言有比异常更加优雅的Error handling方式, 例如Either Monad或者Railway oriented programming。本文虽然不包含这类话题，但至少目前咱们可以用Option来表示这个函数签名：

type GetCardNo = (cardNo: string) => Option<cardno>

这个函数类型清晰的表示了整个考证过程，客户输入一个字符串, 返回一个CardNo类型，或者空。

改写后的领域模型变成了这样:

type CreditCard = {  cardNo: Option<CardNo>  firstName: Name50  middleName: Option<string>  lastName: Name50  contactEmail: Email  contactPhone: Phone}于是，现在的代码拥有跟多的领域知识，丰盛的类型还充当了单元测试的角色，例如，你永远都不可能把一个email赋值给contactPhone，它们不是string, 它们代表不同的领域知识。

领域模型的原子性和聚合性这个领域模型中的三个name可以分别改写吗？例如只改写middle name？如果不可以，如何将这种原子性的改写知识包含在领域模型中？说实话咱们非常的容易就可以把Name和Contact两个类型分离出来并加以组合:

type Name = {  firstName: Name50  middleName: Option<string>  lastName: Name50}type Contact = {  contactEmail: Email  contactPhone: Phone}type CreditCard3 = {  cardNo: Option<CardNo>  name: Name  contact: Contact}让错误的状态无法表示在领域建模过程中，这是一条非常重要的原则，用通俗的话可以理解为：你建立的领域模型应该有尽可能多的静态检查和约束，让错误发生在编译时，而不是运行时，从而杜绝犯错误的机会。其实整个领域建模都是在遵循这个原则，例如上面的Email类型和Phone类型，为什么不用string来表示呢？因为string给与的领域知识不够，从而允许研究人员有了犯错误的机会。

让咱们最后看一个例子，用来探讨明这条原则如何被应用在领域建模中。 上面领域模型中有一个contact类型，包含一个Email和Phone属性。支付成功后，系统可以通过这两个属性给客户发通知，由此延伸出来这样一条规则：客户一定至少填写Email或者Phone来接受支付消息。

首先，上面的领域模型是不匹配这条业务规则的，因为Email和Phone类型都是非空类型，意味着这两个属性都应该是必填项。

咱们能不能把它俩都改为Option类型呢?

type Contact = {  contactEmail: Option<Email>  contactPhone: Option<Phone>}显然也不行，说实话就是违反了让错误的状态无法表示(Make illegal states unrepresentable), 从而给与了代码犯错的机会，你的领域模型表示出了一种非法的状态，即Email和Phone都可以为空，你也许会说我的xxService做了考证呢，它俩绝对不会同时为空。对不起，咱们希望咱们的领域模型能够包含这种领域知识，至于xxService，跟领域模型无关。到底能否将这一规则表示在领域模型中呢？答案是肯定的，规则中有一个“或”字，即咱们可以通过Or类型(union)来表示这种关系：

type OnlyContactEmail = Email type OnlyContactPhone = Phonetype BothContactEmailAndPhone = Email & Phonetype Contact =   | OnlyContactEmail  | OnlyContactPhone  | BothContactEmailAndPhone结束语本文旨在通过函数式编程语言来指导领域建模，整个代码示例中没有出现类或者子类，更加不会出现abstract,bean等关键字，衡量一个领域模型的好坏取决于

领域模型是否内含了尽可能多的领域知识，能否反映领域专家脑海中的业务模型领域模型能否成为文档，进而成为所有人沟通交流和共享知识的途径同时，一些语言，框架的”行话“应该越少越好，例如你在领域模型中创建了一个叫做AbstractContactBase的类，除了增加复杂度，对共享领域模型这一目的帮助甚少。

说实话函数式编程语言的类型系统，不但能够帮助研究者建立一个丰盛的领域模型，同时简单可组合的类型系统，也为代码即文档提供了基本。不可以否认真实世界远比本文所描述的例子复杂，但是大部分复杂的部分，并不会出现在领域模型中，例如函数式编程中的各种”行话“，他们往往出现在数据请求的validation, 请求第三方，数据转化，持久化等实现阶段。

标签： 函数