领域划分的一些思考
为什么要划分
对于一个业务系统，以业务为核心，随着业务发展，在业务和工程侧必然导致以下2种情况的发生
最终导致一个问题：业务支持效率降低
解决的方法： 拆
原则：组织/系统围绕业务的发展进行迭代升级
目标：既需要解决当下业务支持效率降低的问题，又能够很好的支撑业务长期稳定发展。
对于业务初期，通常会采用大的单体工程方式支持早期的快速发展，但是明显的业务膨胀带来代码量的急剧攀升，团队规模的扩大带来协作风险的增加，很难继续支持业务高速发展，故需要进行相应的领域拆分，以保持对业务的迭代的高效支撑，而 DDD 提供了一种从业务出发的建模方法，能很好满足我们的目标要求，故通过领域化，分而治之，进行我们的系统建设。
怎么划分
目的：保持对业务的迭代的高效支撑
目标：
对于领域的划分，一定是围绕着业务进行的，而最终的划分一定满足4个要求
- 全面：能够涵盖直播全部的业务，足够支撑直播大域所需能力
- 清晰：领域职责和边界足够清晰，领域内实体和能力的定义足够明确
- 应变：稳定支撑现有业务的同时，能够高效的应变业务的变化，维持其迭代效率
- 粒度：符合当前业务&团队规模
原则：
领域化原则
- 互斥——垂直领域互斥、子领域间互斥：一级领域参考电商线 要互斥（如领域：营销、交易、物流、售后），二级领域参考领域内模块划分 要互斥（如商品领域内的二级子域，包括商品、库存、价格），保证外部边界清晰；
- 分层——领域内上下分层、并保持一致：某一个领域在开发服务的分层次对应，包括API/Gateway接入层、Service微服务、异步任务、数据库、API/Page的Path，具体参考开发代码规范环节对不同层的落地规则如何保持一致，保证垂直边界清晰；
- 重用——领域间依赖、重用其他领域能力：域和域之间保持强依赖，对其他领域依赖的需求一定要在其他领域提诉求实现，反之自己的域也要承接其他所有域的依赖，以构建闭环的领域生命体；
领域定义原则，回答下列问题(只要你能回答这3个问题，你就是个领域，至于要不要拆除独立定义，得看粒度)：
- 领域职责（愿景）是什么？
- 领域的问题空间边界是什么？
- 领域核心实体是什么？
拆分方法：
需要明确的是我们做的是业务建模工作，首先需要的就是全面了解业务，了解业务的方法有很多种，比如事件风暴，比如uml建模，比如阅读代码，甚至是请教领域专家，但是在做划分之前，一定要保证对业务的全面了解，并且对业务发展有足够的前瞻意识，以顶层视角来进行领域划分定义。下图只是展示了2种参考路径，有个明确共识，领域是基于业务认知结合现状拆聚出来的，最终团队达成一致。拆是为了保证摸清全部业务脉络，聚是为了寻找共性，进行抽象。最终满足上述原则和目标。
【洞察业务】对于具体的业务，我们基于已有的了解上，可以通过白盒化的方式，完整的梳理业务的业务流，
【描述业务】我们可以用直播业务来说明下，下面的框图对直播业务进行完整描述：
以上框图可以完整描述一级领域直播的全部业务。直播间是一级直播领域的核心实体，对于其他一级领域也是以直播间作为聚合根提供服务，直播间的实体包含主播信息和直播间信息。整个业务围绕直播间展开，以此为基础进行分发、消费、互动
能够支撑业务发展，各框图其边界清晰，有自己明确的定位和业务目标，业务规则均可聚合在各框图，业务侧的动作均是在此流程上建立
能够服务到全部生态角色，生态参与者(主播/公会)均有独立明确领域为其提供服务能力
符合当前团队/业务规模，这些领域能否细化？答案是必然的，但是细化之后不可避免的带来资源的浪费(服务过多，负载较低)和维护成本的增加(单人维护的服务数过多)，得不偿失，因此我们认为以此粒度基本符合当下团队规模。
【适配业务】对于这块，我们还是希望领域的划分与业务的发展目标保持一致，这里既包含团队分工，也包含业务目标。 我们会尝试以领域愿景(愿景本身可以随业务发展而迭代)串联业务和工程能力， 故以此为基础，进行领域划分，明确职责，团队达成一致
我们尝试用Q3的需要占比已经需求跨领域的数量，来浅浅的示意我们这种领域划分的方式与实际业务的契合程度，仅做参考(不会是唯一衡量指标)
怎么评价划分好坏
关于指标的定义，回到划分的目的上，为了保持对业务的迭代的高效支撑。因此，可以从这个指标三角形的角度来权衡领域划分的目标和收益
- 稳定性
- 研发效率
- 应变能力
事实上，领域的划分是一个相对动态的过程，在这个过程中过，我们会持续用需求的闭环率、各领域的需求pd数、工程代码量、资源分布等维度去动态观察划分的合理性。
拆了之后
领域化的起点是针对当前系统迭代效率&协作风险和业务高速灵活发展之间的矛盾，提出的一种解决方案，但是领域化不仅仅是工程技术层面的问题，更多的是需要围绕业务领域出发，经过领域化分拆重塑脉络之后，也是希望技术同学能够在各自领域多一些业务知识的积累和沉淀，能够有自己的业务思考，从领域愿景出发，更好的用技术去赋能更多的可能性，助力业务起飞，而不单单是实现产品1/2/3功能的工具人。
