面对需求，我们首先想到的是什么
在家电IoT这个领域里，通常都会需要实现家电的分享。比如老婆分享家里的电饭煲给老公，让老公控制电饭煲。
拿到这样一个需求，通常大脑里想到的就是增加一张家电分享表来实现：
| appliance_user_shared |
|---|
| master_user_id |
| shared_user_id |
| appliance_id |
然后再修改家电列表的实现，因为需要将别人分享给自己的家电也要能获取到。
同时，别忘记了，我们还要修改所有对于家电的操作的实现。比如业务规则中说明，家电的主人才能对家电的名称进行修改。
就这样，我们实现了用户对于一个家电的分享。这时的业务模型可以表示如下：
过不了多久，产品经理跟你说，如果一个用户家里有10个家电以上，一个个家电的分享，这种体验太糟糕了，我希望将一个家庭分享给其他人，这样，可以将家庭下所有的家庭一下子分享给另一个人了。
当然，我们同样可以将这个需求，看作是添加一个家庭分享表，再修改一下家电列表、家电名称修改、家电控制……这是A方案。
A方案的领域模型表示如下：
但是，我们还有一个B方案。
当我们仔细思考时，我们似乎掉进了产品经理挖的坑：产品觉得通过增加一个“分享家庭”的概念来实现多个家电的分享。
事实上，我们服务器端实现并不一定需要这样做。前端APP可以有一个家电分享的操作界面，但是，服务器在实现这个web api时，只需要在找到这个家庭下的所有家电，然后重用原来单家电分享的概念了，就可以了。
这样做，就非常符合软件设计的开闭原则：对扩展开放，对修改关闭。
基于B方案，我们不需要对家电列表等功能进行修改。同时，你还会发现，某天产品经理抽风，觉得一次性分享所有的家电不好，如果能在一个家庭基础下实现部分家电分享的功能，是不是更好？A方案就头大了。而B方案可以很轻松的应对。
B方案的领域模型表示如下：
说回来，我们应该警惕产品经理或需求人员帮我们做软件设计。
面对需求时，我们的大脑里，第一想到的是数据库表如何设计、如何实现改动最小、是使用微服务呢，还是使用七边形架构……这类技术问题时，我们的设计是技术驱动设计的。
如果我们大脑里第一思考的是什么单家电分享、家庭分享和单家电分享之间是什么关系……这类领域问题，然后基于这些思考，建立一个领域相关的知识体系——以领域模型为体现。如果我们的软件是基于此领域模型进行设计，就是：领域模型驱动软件设计。
按《领域驱动设计》中，作者所说的：
领域驱动设计是一种思维方式，也是一组优先任务。
领域建模
要搞清楚，什么是领域建模，就必须搞清楚什么是软件的核心。
我们来看看《DDD》前言里所写的：
一些设计因素是技术上的。软件的网络、数据库和其他技术方面的设计耗费了人们大量的精力。很多书籍都介绍过如何解决这些问题。大批开发人员很注意培养自己的技术，并紧跟每一次技术进步。
然而很多应用程序最主要的复杂性并不在技术上，而是来自领域本身、用户的活动或业务。当这种领域复杂性在设计中没有得到解决时，基础技术的构思再好也是无济于事。成功的设计必须系统地考虑软件的这个核心方面。
这个核心方面指的就是领域知识。
而领域建模就是消化吸收大量知识（领域相关），最后产生一个反映深层次领域知识并聚集于关键概念的模型。这也就是领域驱动设计的实质。
上文中，关于家电分享的例子，从A方案到B方案，实际上就是随着我们对领域知识的理解更深入，领域建模的一个过程。
小结
就如《DDD》作者所言：很多因素可能会导致项目偏离轨道，如官僚主义、目标不清、资源缺乏，等等。但是真正决定软件复杂性的是设计方法。当复杂性失去控制时，开发人员就无法很好的理解软件，因此无法轻易、安全地更改和扩展它。
领域驱动设计这种思维方式，再加上一整套的设计实践、技术和原则，就能帮助我们控制真正的复杂性。这就是领域驱动设计的作用。
而这种思维要求我们在面对领域问题时，优先考虑的是领域问题，而不是技术问题。
注意，这并不是说我们不考虑技术如何实现。这是优先级问题。
最后，以上举的例子并不是最终的模型。因为家电分享这个概念并不是最根本的概念。更根本概念是家电的权限。这是一个更层次的领域模型：
