在前面提到过，领域驱动设计其实就是业务驱动设计，只是业务更直白一些，领域更抽象一些。领域驱动设计，其实就是将实际业务场景具体细化，然后经过此业务领域的专家和设计、开发人员通过某种共同的语言，发现并生成领域概念，抽象出反映真实世界的领域模型。这也就是经常提到的面向领域的思维方式。
领域驱动设计主要有两个大的步骤：
1、由具体的型业务抽象领域模型
2、由领域模型来驱动完成软件代码设计开发。
领域驱动设计其实开始并没生成多大的水花儿，至少在国内是如此，只是随着近些年移动互联网的快速发展，人们看到其中的一些奥妙所在，才逐渐重视起来。
领域驱动设计的思想就是要有领域的思维，要能够利用领域的思想去指导整个型业务需求向软件设计的转化。换句话说，要对业务有着更高层次的认知，而不能仅仅停留在对业务的了解，所谓更高层次的认知，就是抽象。所以，领域驱动设计的核心就是MDD，也就是模型设计。一个使用通用语言设计的好的模型，能够更好的让整个程序的各个环节的人都积极主动的参与进来，而又能较好的去除一些“杂音”。因此，领域层是模型的精髓。
那么何为领域？可以理解成型业务的边界，颗粒化业务的整体的上下文的环境。所以对领域的理解的深刻程度，决定着领域驱动设计的优劣，也决定着模型的生成的弹性和可伸缩性的大小。而这也是在领域设计中最常见的分离领域形成领域分层的重要的原则和手段。
领域驱动设计可以从两个更高的层次上分成两部分：
1、DDD的战略层次的设计
战略上重点是对问题空间和解空间的两个方向上进行分解控制。
2、战术层次上的设计
战术则是在对战略限定的具体的子空间内进行受限的环境上下文和边界上进行设计。
战略和战术的设计是辩证统一的，这个勿需多言吧。
在设计一个领域模型时，一般有以下几个步骤：
a、由实际需求创建一个初步的领域模型，并根据具体的领域和相关关系，用通用语言描述之；
b、根据实际功能对整个应用层分类，并进一步划分应用层和领域层；
b、细分领域模型，划分出实体，值和对象，以及领域服务；
f、对领域中的关联关系进行分析，去除杂音；
e、找出边界用来聚合并确定聚合（AGGREGATE）根，这个需要不断的实践总结；
f、确定聚合根和仓储的设计分配以及接口控制；
g、检查场景与设计的领域模型的适配度并不断完善；
h、考虑领域实体或值的构建方式采用哪种方式（直接或者使用工厂）；
i、不断迭代重构领域模型，不断完善修改领域模型。
在这里可以看到，其实领域驱动设计就是针对业务的具体场景的抽象，是不同的业务不断的细分下的抽象。在目前，想着搞一个中台搞定所有业务，看上去很美，其实却是和实际背道而迟。或许，在未来的某一时刻，随着技术的演进和思想能力的提高，有可能实现这一宏大的目标。但是那却是另外一回事儿。
讲现在的故事，说现在的业务，实事求是。