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