小区楼下有个卖烤红薯的。
时常路过，就买一个。
这天想。
如果我是一个卖烤红薯的个体户，我的工作主要有哪些。
那么，大致会分为两部分。
第一部分是我要生火烧炭，观察红薯的状态，并且将熟透的红薯挑选出来放到恒温箱。
第二部分是我要定价，考虑红薯的进货成本，还要考虑促销，如何能卖出更多。
这里面，第一部分跟业务没有多大关系，更是一个技术活，不需要【运营】，第二部分跟业务有关系，是需要销售人员这样的角色参与进来，需要【运营】。
如果我们为卖红薯这个行当做个应用系统，那么这个系统中就分为了两部分：“与运营无关的部分；提供运营能力的部分”。
现在你要为这个卖红薯的业务进行建模了。
那你应该重点考虑哪一部分呢。
所谓的建模，就是将业务中的问题表达出来，如何表达，可以使用一些图表，比如流程图，比如一张数据表，都可以是建模。
什么是业务，就是流程、交互、规则、功能等等。把这些内容放入刚才说的图表中，或者是被这些图表体现出来，就是业务建模。
业务建模就是这样一个过程。明确业务中的关键问题，使用易于实现的模型将业务问题表达出来。
那么。
这里我们说的是业务建模，卖红薯的第一部分工作属于业务吗。
提供运营能力的部分是业务。
因此，第二部分是业务，第一部分不属于“业务”，更像是技术领域。
比如，对于类似 Google、Bing 这类搜索引擎而言，与运营无关的部分是搜索引擎，而与运营有关的则是广告的投放和竞价。对于类似优酷、爱奇艺这类视频网站而言，与运营无关的是流媒体部分，而与运营有关的则是 VIP 账户、广告等。
自打有领域驱动这门技能起，学习DDD也好，学习其它的建模方法也好，领域、业务中的知识学习和运用都是有一个较高的门槛。我们要学习知识，更要跳出知识之外来运用知识，将知识形成我们自己专能。
“知识和专能差异巨大，凭借知识可以推断出该做什么，而专能让你甚至在无意之间，条件反射似的把事情做好。”
业务建模的方法之一，领域驱动设计，往往也是业务建模的首要方法。
软件开发的核心难度在于处理隐藏在业务知识中的复杂度。
有一个好的模型，是对这种复杂度的简化与精炼。
那么，你今后就要思考，仔细思考，你的业务中，到底哪些是业务，哪些领域。
对，领域和业务是分开的。
多数人为了逃避真正的思考，愿意做任何事。而如果程序员为了逃避理解问题并给出定义，最后通常就会成为只会倒腾各种技术方案的架构师。
“领域”表示与运营无关的问题域，“业务”表示与运营相关的问题域。
在搜索引擎那个例子中，搜索引擎的核心功能是领域，围绕搜索引擎之外有广告的投放和竞价，这是业务。
在设计时，领域和业务都适用于弹性优先原则。
什么是弹性优先，在我看来，这里的弹性可以理解成：变化。变化原因和变化频率。有一样的弹性诉求，那么就是有同样的变化原因和变化频率。所以，细心的同学就会发现到，微服务应该什么时候“拆”。我们其实也可以利用这个规则。
如果两个上下文明显具有不同的弹性诉求，那就应该拆分。而如果具有一致的弹性诉求，就可以不拆。
“一旦领域层出现重大改变，就意味着重大的业务调整，整个系统都可以推倒重来了。因而在软件系统有限的生命周期内，我们可以认为领域层应该是不变的。”
----END----
这里记录，我每周碰到的，或想到的，引起触动，或感动的，事物的思考及笔记。不见得都对，但开始思考记录总是好的。
与爱学习、爱思考、爱记录的你共勉。
参考资料：https://time.geekbang.org/column/article/395650 《如何落地业务建模》
