接下来我们将要开始重 DDD 的战略设计来开始谈谈，别忘了战略的重点在於 :
如何切
然後还有个金句要记录一下 :
DDD 不看功能，而只看流程
基本上战略设计主要有三个目的 :
然後完成以上战略设计目的方法论，目前比较有名的有二个，之後的文章会谈到 :
接下来这篇文章先来谈谈，这三个战略目的。
这个目的是理解 domain，并且将大的切成小的，才好解决，并且建立统一语言，才能在未来讨论与建立软件模型时，说一件事情，都是指同一件事情。
根据 《 中台架构与实现基於 DDD 和微服务 - 欧创新 》这本书中对 Domain 的定义为 :
Domain 是从事一种专门活动或事业的范围
然後在这篇文章中，我看到了一个注释，我觉得的非常有理 :
你在工作上面对的问题 + 解法 。
所以总结一下，我自已对 domain 的看法 :
Domain 是一种业务范围，包含了问题 ( Problem Space ) 与解法 ( Solution Space )。
所以 domain 事实上是业务的『 问题 』 + 『 解法 』，但是我们开发人员很多时後的系统设计是以『 解法 』又或是说『 技术 』为基准，这也导致架构与业务是分开来的，才会发生想以『 业务 』来切『 微服务 』那麽的困难，因为根本没有以『 业务 』为本。
基本上你待在一间公司，那间公司做的东西，对那间公司来说就是一个 domain，不过他就是个大泥球，可以想成是少数几个人记在脑海里的东西，但是他的范围与要做的事情，不一定有明确的定义。而 DDD 战略目的就是要将他定义清楚。
接下来我们要谈一下这个目的下，要找到的几样东西 :
DDD 会先将这个 domain 的范围定义好，接下来会再将它们分成 subDomain，因为要解决大问题就要从小问题开始解，最後在根据每个特性，产生出以下几个东东 :
现阶段很多公司，很多单一系统所处理的 domain 已经过於庞大了，不先想办法切分，你就会看到一团大泥球，你完全切不动，然後最惨的就是後端工程师，因为全公司平台上的 domain 都是你们做的，这导致每个部门一有事就来问你们，而如果後端工程师少的情况下，几乎每个工程师都会变成最理解公司 domain 的人。我待过的公司就是这样… 惨。
有时後想想新创的後端真的惨，各部门 domain 被寻问人、feature 开发人员、sre 维运人员、分析资料产出人员、mis… 我还看过有人当水电工的…
简单的说就是一个词，每个人所理解的意思是相同的，然後之後都用这个词来沟通与建模
如果没有它会发生 :
目的是要知道我们所写的程序码 ( 解决方案 )，要处理的范围情境是什麽
为什麽要谈到 domain 一定有讨论 bounded context 呢 ?
因为一个名词在不同地方，意思换了，那个『 地方 』就是个『 Bounded Context 』
假设当一个用户在网页上看到一个产品 product，然後下订单『 里面有该产品 』，最後会在将这个『 产品 」运送给用户，所以这时 bounded context 事实上有三个 :
一个『 product 』 在不同的情境下，会有不同的意思，也代表有不同的状态变化，如果都它将做成同一个，你的产品里面会存了一堆需符合所有的 bounded context 的状态。
这里简单做个总结 :
一个词例如 product 是模糊不清的定义，只有在『 Bounded Context 』下才能得到完整的定义
假设我们有一个 Product 模型 ，然後他一开始有以下的栏位 :
class Product{
id: string
title: string
category: string
describption: string
}
然後由於它是个产品，所以可以给人买，所以又需要『 购买 』的一些栏位。
class Product{
id: string
title: string
category: string
describption: string,
// 购买情境
price: number
discount: number
}
接下来因为它是实体产品，还需要加上『 库存 』相关的栏位。
class Product{
id: string
title: string
category: string
describption: string,
// 购买情境所需
price: number
discount: number
// 库存情境所需
qunatity: string
location: string ( 库存在那 )
supplier: string ( 产品供应商 )
}
然後最後还需要『 运输 』相关的栏位。
class Product{
id: string
title: string
category: string
describption: string,
// 购买情境所需
price: number
discount: number
// 库存情境所需
qunatity: string
location: string
supplier: string
// 运输相关所需
taxable: string
shipmment: string
}
到最後你就会得到一个包山包海，要切也不知道如何切的东西，而如果事实就知道 Bounded Context 那就可以分了。
目的为从流程上探讨，Context 间交互关系与交互的重点。
这个地方我建议直接看这篇文章，我觉得超棒的。
战略设计：来聊聊 Bounded Context 的世间情 -- Context Mapping
>>: Day25 React useReducer - 另种管理state的方法
各位早阿，今天就接续昨天的部分，继续抓取留言和汇出成json档吧! 留言区 观察一下PTT的留言区，...
经过了连续5篇复杂度略高的物理模拟系列，我在想看官们多少会有点疲乏~ 所以我在规划了几篇『中场休息』...
Arc 和 Google Analytics Insights都是可以拿来介接Google Ana...
前言： 今天是第26天啦，阿森在整个开发的部分也差不多完成了，准备进入最後上架测试阶段！ 在上架的...
https://typeorm.io/#/repository-api 常常在使用，但也只有使用到其...