前几期的文章，主要给大家描述了领域模型的概念和用法。针对互联网软件开发流程中，领域模型技术实践比较倾向于给大家传递良好的编程习惯和思路，适用于当前的开发人员。
但我自己在总结梳理以及结合个人经验的同时发现，这里面其实也有很多思维同样适用于产品人员，分享出来希望给大家一点启发。
如何开始调研设计产品当我们置身于一个陌生业务领域时，看不清业务全貌甚至存在很多潜在场景，困惑和不知所措是大多数的人状态。
针对这种情形，领域模型中关于研发人员从哪里敲下第一行代码的讲解能带给我们一些启发。常规来说，一般在研发前会进行设计，无论是数据库还是时序交互，一般都是由下而上，打好地基再来搭建上层建筑。
（领域模型技术实践提倡的开发习惯）
但把我们自己放进真实的工作场景中，其实会发现即使业务本身比较明确，在设计的时候考虑数据库结构的字段，业务间的数据交互等等时还是会有一些困惑。这种工作由下而上的方式很多时候会演变成为了设计而设计。
所以我们会建议大家先从确定性的功能业务开始写代码，当所有确定性的东西完成后模糊的东西会更加清晰，在这个过程中我们底层的结构会自然清晰。
对于这种思维方式，我觉得同样适用于产品工作。任何业务领域中从基本或确定性场景出发，慢慢拓展，能够高效地帮你尽快熟悉陌生业务领域。
在这里我们拿电商购物的场景举例，我们从用户购买这个核心场景出发。在梳理时，尽量先补全业务全貌，不要急于去思考细节。
从确定性业务场景出发，我们能比较快速地补全主流程的业务线。再在各个流程业务间去考虑其他相关因素，慢慢补全整个业务全貌。
（学会用业务滋养中台）
这种方式能比较快地帮助我们探索一个陌生业务领域，但在梳理的过程中一定要从主干出发，切勿一开始就深究细节。用业务本身帮助完善我们的业务领域模型。
学会拆分产品形成边界之前我们有提到一个概念叫业务领域模型，在实际操作过程中我们的业务领域模型需要区分核心域和公共域。
核心域其实就是业务的核心本质，不同于公共域消息、权限等比较常见的业务。因此我们需要对我们的领域模型以及产品进行拆分，从而形成边界。
拆分的原则其实就是遵从业务本身，围绕业务能力进行组织。这里我们还用之前的乘车业务举例；
可以比较清晰地看到，拆分的结果分为核心和公共两个部分。针对大多数的微服务架构，就是根据这样的业务模式进行拆分。拆的过细或者太粗对于微服务和业务领域都没有太大价值，所以还是要以业务本身为准。
大家也可以根据整个服务的拆分，自己去梳理整体的业务流程。
用资产的眼光去看待产品并保持演进不管是业务领域模型还是产品本身，一定都存在一直迭代的过程。对于迭代，我们需要承认的是产品本身的不完美和缺陷。但这也是任何产品自身的宿命和现实，世界上根本不存在完美的事物。
对于现有的代码和业务领域模型，我们一定要用资产的眼光去看待。资产本身会有一个欠债的概念，当我们的代码在实现过程中没有真正考虑复用性，只是为了实现需求，本身其实就相当于欠下了无形的债务。
当业务扩张时，会发现我们的代码完全支持不了业务本身，这个时候其实就是还债的过程，对于业务领域模型也是同样的道理。
任何过度设计，缺陷设计下的弊端总有一天会暴露出来，欠下的债务也一定需要偿还。好了，这次的领域模型讲解就到这里，对于领域模型我也梳理了大纲，有兴趣的朋友可以看看。
（领域模型技术实践个人梳理）
我是红尘，我们下期见！（公众号：都市摆渡人）
