前言
DDD分为战略设计和战术设计，战略设计就是划分子域和限界上下文的过程。领域划分为子域的通用划分形式是把领域划分为 核心子域、支撑子域、通用子域。我们在落地过程中常常会很容易划分出核心子域，因为核心子域是领域赚钱的核心逻辑嘛，一般设计mvp的时候mvp就是核心子域。但是领域划分出核心子域、支撑子域和通用子域之后就算划分完成了吗？
子域和限界上下文
实际上子域也是领域，一个公司不同部门关注的是一个大领域的不同子领域，在你关注的领域内也需要做这种子域的划分。比如腾讯这个大公司，有很多部门，这些部门都属于互联网领域，但是每个部门又有自己关注的领域，比如游戏部门关注的是游戏领域、微信部门关注的是微信领域。不同部门的领域还可以再继续划分出自己关注的领域的核心域和支撑子域。所以整体上，领域的划分就是一颗树。
我们回到自己关注的领域，基于这个领域做划分。我们会把这个关注的领域划分为核心域、支撑域和通用域，一般每个域都由一个小团队负责（康威定律）。如果一个团队的工作是支撑域，那么这个支撑域就是他们的核心域，他们可以对此再做细致的划分，何时划分到头呢？用一个具体的限界上下文解决这个叶领域的所有问题，并且领域通用语言在这个上下文中没有二义性，那么就算划分到头了。
划分到树叶的领域都是待解决的问题，也叫问题域，而限界上下文呢就是用来解决这个域内所有问题的模型。针对限界上下文与领域的对应关系Vernon给出了建议，最好是1：1的关系，当然也有其他说法如1：N，N：N，本人认同Vernon的说法，如果子域对应多个限界上下文，那么只能说该子域还可以再划分为子子域，由子子域去对应每个限界上下文。
划分好子域和限界上下文后，限界上下文的主题就是解决这个子领域的问题，手段就是DDD战术建模，工具就是领域通用语言，限制就是领域通用语言不能有二义性。
落地过程中遇到的问题
在落地过程中我们遇到了一个建模问题，我们的服务有两个角色使用，一个角色是运营人员，运营人员要配置模型的各种规则，但是频次相对较低。另一个角色是用户，用户会使用运营人员配置的规则，使用频次较高。在项目初期由于团队没有谈拢，最终放弃了拆分这两个上下文，而是使用相同的上下文进行了建模。
这个问题的本质是我们没有想好领域划分，现在回头想想，我们处理的是一个核心域，但是这个核心域又可以分为两个子域，一个是配置平台子域、一个是用户使用子域，两个子域的关注点是不同的，并且变化频次也不同，后续用户使用上下文会做横向扩展，我们目前的单体架构虽然能做扩展，但是不符合单一职责原则，因为用户使用平台集成了配置功能，而配置功能是不应该随着用户功能进行扩展的。
在拆分过程中，会有很多代码是重叠的，我们的服务中就有很多Aggregate聚合，在两个上下文中有很多字段是一样的，但重复并不一定是错误，因为重复的代码关注点和变化频率是不一样的。
这里我们介绍了利用角色进行关注点区分，进而划分子域和限界上下文的方法，实际上也可以根据其他条件对领域进行划分，划分只要保证概念相对独立，关注点相对独立，划分后没有丢失问题就可以。
划分领域（限界上下文）的依据
- 通用语言：在做领域划分之前一定要统一领域通用语言，如果一个名词在用语言描述的时候在不同语境有不同含义，那么就应该在不同语境中创建不同上下文。比如book，在写作阶段就是草稿，在出版阶段就是一个出版物，在购买阶段是一个书籍类商品，在发货阶段是一个物流订单。那么就应该按照书的角色进行归类，区分出上下文。正所谓，在商言商，在领域就应该说领域的通用语言。
- 领域职责：不同领域想要达成的目标是不一样的，每个领域都有自己最终要完成的事情，即通过领域知识，完成领域活动，最后完成领域职责。
- 领域角色：不同领域的角色也不尽相同，前端领域里可能需要ue角色、fe角色。后端领域里可能需要java研发、dba等角色。同时上边举得book的例子，book在不同领域的角色也是不一样的。再通俗一点，你在学校是学生角色，上班是员工角色。
- 领域知识：不同领域包括的知识是不一样的，比如后端和前端，后端可能需要了解服务器相关的知识、前端需要了解的是界面相关的知识。
- 领域活动：不同领域的职责也是不同的，在领域内进行的活动也不一样，比如前端需要构建前端页面活动。后端处理数据库交互活动。领域活动会利用到领域知识，如果进行领域活动的时候却不具备这个领域的知识，那么说明领域划分是不合理的。
- 领域关注点：不同领域关注点不同，拿person举例，person有身份证信息、年龄、身高、体重、工作、专业等信息，但是在不同领域对person的关注点是不一样的，银行办信用卡不需要身高体重信息、参加奥运会却关注身高体重，相亲时不会关注身份证信息，但却关注你的工作、年龄等。
