前面两节絮絮叨叨重点讲了一句话：领域驱动设计的核心在领域模型，领域建模核心在精通领域业务。那么该如何做好领域建模呢？需要精通的能力都没有捷径可走，但是也不是没有方法可循，下文就领域业务和建模两方面做一下讲解。
做好领域建模，首先要做的工作是要精通领域业务知识，那么领域业务知识从哪里来呢？前面章节讲了从事软件研发的工程师并非全部来自于科班出身的学生，有些计算机相关学科天然带着领域业务知识，例如GIS专业。这些专业的学生从事该专业类软件开发，首先已经具备了该领域的专业知识，在进行需求调研、整理，以及内部沟通时使用的都是通用的语言，大家对于模型应该是什么样已经达成共识。
而对于现在从事互联网软件开发，我们面对的业务领域也许是一个全新的领域，是产品经理基于用户痛点，构思的一个全新的软件工具，此时，我们该如何构建我们的领域模型呢？领域模型，一定是一个名词，那么我们就可以以此为出发点，列举软件用使用到所有名词，然后对名词进行分类，再对归类到同一类型的众多名词进行提取核心名词，然后画出核心名词和该类别中的其他名词之间的关系图，最后抽象出该类别名词拥有的动词。
以支付系统的用户信息为例，第一步列举所有名词，并进行分类；第二步提取各组关键词；第三步抽象出各个领域的动词，如下图：
领域模型划分尽量保证业务的高内聚和低耦合，划定领域边界，保证一个业务逻辑尽量在一个领域模型内部，领域模型之间尽量少业务来往，领域模型划分尽量保证，一次业务流程涉及尽量少的领域模型。
领域模型的构建过程中必须要业务专家/产品经理保持实时沟通，在模型的构件上保持统一的语言。最近在读金字塔原理，其中讲到归纳性思维和演绎性思维，人的原始思维方式是演绎性思维，这就决定了，我们经常会基于流程的去思考问题，而面向对象建模恰恰需要的是归纳性思维。如果我们研发采用面向对象思维构建软件，而业务专家/产品经理基于业务流程的方式和我沟通，势必驴头不对马嘴。
做好领域驱动设计，必须在领域建模时叫上领域专家/产品经理一起讨论设计，保证所有参与产品设计开发测试的人员，在统一的领域通用语言层面沟通。例如，产品经理会和我们讲用户找回登录密码，用户第一步要怎么做，第二步要怎么做，第三步要怎么做，最后得出什么效果。而基于领域模型的通用语言应该是登录密码应该拥有找回密码的动作，完成该动作需要做第一步、第二步、第三步。
对于已经做了很久基于流程模式做软件开发的工程师，转向领域建模需要一个适应过程，基于流程开发和基于模型开发是两个完全不一样的思维方式，我们需要将代码的业务逻辑封装在一个对象中，而不是流程中。对于spring这样的框架构建起来的系统，整个工程中全部采用单例模式，满屏的事务脚本，需要的代码逻辑信手拈来，而基于领域模型的代码中，任何一个业务逻辑需要细心的打理，将业务封装在最恰当的领域对象中，因为该逻辑只能在整个工程中存在一处，而且要保证该业务逻辑尽可能少的跨领域模型。既然使用领域模型开发这么麻烦，那么为什么还要采用领域模型的方式开发呢？因为领域模型能够比事务脚本更好的管理大型业务逻辑。