在Eric Evans 的领域驱动设计中提到，领域驱动设计作为一种思维方式，根本目的是为了加速那些需要处理复杂领域的软件项目开发，应对软件核心复杂度的挑战。那么软件的复杂表现在哪里，在《A Philosophy of Software Design》中提打到：Complexity is anything that makes software hard to understand or to modify,任何使软件变的难于理解和修改的因素都是复杂性。

随着需求的变化，系统规模会不断扩张，软件复杂度会增长，除了需求功能本身的增加，还有功能之间的联系变的牵一发而动全身，并且这个复杂度的增长往往是指数级的趋势，在构建软件过程中，无法避免的技术债造就软件无法躲避的熵的增加。这样造成了软件相关人员需要掌握大量信息，提升自己对业务需求和软件的理解。

为了满足非功能性质量需求，例如高性能，高并发，我们考虑在系统中引入缓存，并发处理，CDN，异步消息，海量数据的分布式存储，海量数据的高效分布式计算等这些都让系统在结构上变的复杂。
为了保持系统有序，提高代码可维护性，我们利用分层架构达到不同层次职责分离，但这种分解，也带来了沟通成本的增加，管理上的挑战，这一点在康威定律（Conway’s law）早已说明，任何组织在设计系统时，所设计的方案在架构上都和该组织的沟通结构保持一致。

为了降低业务复杂度，我们拆分不同的子领域，但是往往因为守不住领域的边界而丧失了拆分的价值，系统结构会变的越来越混乱。结构上的混乱，会让软件的修改变的不确定。

在设计软件系统时，设计人员是无法完全预测系统的变化，一方面可能过于考虑变化的影响，而进行了过度设计，但是预期的变化未发生，那么过度的设计所付出的成本就是浪费，另一方面，如果不对变化做任何的预测，系统会非常的僵硬，不停的因为变化而不断的付出较大成本。

参考图1-1，这些软件系统本身客观的结构,规模，变化复杂性都阻碍了开发人员对系统的理解，为了应对这些复杂姓对开发人员在理解能力，认知增加和预测业务变化方面有较高要求。

^图1-1

领域驱动设计引入了一套提炼为模式的设计元模型，对业务软件系统做到了规模的控制、结构的清晰化、和变动的响应。

• 领域驱动设计面对业务需求，由领域专家和开发团队进行需求分析和知识提炼，从问题的需求中提炼统一语言，通过分而治之拆分领域，分解问题空间，确定核心子领域，通用子领域和支撑子领域，根据业务能力划分出不同的独立自治的限界上下文，再通过上下文映射管理它们之间的关系，参考图1-2。
  每个限界上下文都是一个独立的自治单元，根据限界上下文的边界，划分团队，团队为所属的限界上下文负责，团队除了需要了解限界上下文的协作接口，确定上下文映射的模式，就只需要了解边界内的领域知识，建立各自的领域模型，通过限界上下文的分解控制系统复杂度。

^图1-2

• 软件系统的构建本质是从真实世界的问题中寻找解决方案，真实世界的客户需求可以简单分为业务需求和质量需求。质量需求一般包括安全，高性能，高并发，高可用性等，往往在技术实现上带来挑战，为了避免业务需求带来的业务复杂度与技术实现复杂度混合，需要确定业务逻辑和技术实现的边界，隔离两者，这种隔离也符合关注点分离的设计原则。领域驱动设计引入的分层架构规定了严格的分层定义 ，将业务逻辑封装到领域层，支撑业务逻辑的技术实现放到了基础设施层，领域层之上的应用层一方面暴露应用服务接口，另一方面又充当业务逻辑和技术实现的协调器，参考图1-3。实际分层架构在实践中已经有多种演化：Clean Architecture中的整洁架构，Alistair Cockburn提出的六边形架构，Jeffrey Palermo 分层思想的 洋葱架构。

^图1-3

• 领域驱动设计通过领域模型针对限界上下文进行领域建模，形成结合分析，设计，实现于一体的领域模型，对业务需求抽象过程中，提取领域知识，保留面对变化时的扩展性。Eric Evans给出了战*术的设计元模型，通过领域服务，领域事件，实体，值对象等来表示模型，并通过实体和值对象访问资源，维护完整的聚合，进一步对聚合和值对象进行封装设计，在实际设计和实现中做到对变化的响应。

领域驱动设计体系构建在设计元模型的基础上，并没有特别的规范指导设计的过程，那么如果没有掌握其精髓，和较高的技能比较难合理运用这些设计元模型，领域驱动设计缺乏一个系统的统一过程作为指导，团队在运用领域驱动设计时，较多取决于设计人员的行业知识和设计经验。

针对Eric Evans的领域驱动设计，社区中也提出了一些不足和解决方案或模式。

1. 领域驱动设计缺乏规范的统一过程指使其设计过程更具可操作性。

2. 领域驱动设计缺乏与之匹配的需求分析方法探索明确的问题和领域知识。

3. 领域驱动缺乏规范化，具有指导意义的架构体系，使从需求到限界上下文和上下文映射的识别，到业务架构，应用架构，技术架构的分析对应提供参考。

4. 领域驱动设计缺乏固化的方法指导领域分析建模、设计建模，实现建模过程，主要凭借建模人员的经验。

在张逸的《解构领域驱动设计》中提出领域驱动设计统一过程（Domain-driven design unified process,DDDUP），相信很多人对统一软件过程（Rational unified process,RUP）并不陌生，不同于RUP的软件项目管理过程，书中提出结合领域驱动设计对问题空间和解空间的阶段划分、对战略设计和战*术设计的层次划分，将DDDUP分为三个连续阶段：

全局分析阶段

架构映射阶段

领域建模阶段

每个阶段都规定了里程碑和产出物，参考图1-4

^图1-4

下面以bilibili OGV业务为例，如何做领域驱动设计的问题领域分析，能够通过一定的分析方法，输出相应的可清晰识别的结果，让我们逐步认清业务问题。

领域驱动全局分析主要目的是明确问题，输出价值需求和业务需求，从价值需求维度搞清楚问题的界定和约束，获取利益相关者，系统愿景和系统范围；在业务需求维度梳理业务流程弄清楚其中每个角色（利益相关者）如何参与到一个完整的流程中，可视化的输出业务流程图与业务用例等说明每一个提供业务价值的业务流程，通过业务用例呈现角色和目标系统的功能性*交互，在这个阶段只是对问题的探讨，无需考虑如何实现的细节。

在《有效需求分析》中将应用类软件需求通过目标/愿景分析，干系人识别，干系人分析关键任务分析价值主线需求；通过功能需求，数据需求，非功能性需求分析的关键任务等识别业务详情需求。
解构领域驱动设计的书中，作者提到全局分析的5W模型，参考图2-1，通过探索这5W关键要素，搞清楚问题领域。

在图2-1中，首先需要通过分析问题相关的利益相关者（干系人），和这些角色通过访谈，头脑风暴，讨论等方式获取系统的愿景目的，针对愿景目的，分析达成目的，解决问题的业务需求有哪些（提供什么样的产品或者系统来达成对应的愿景），这里在下文的业务需求分析中会通过业务流程和业务场景的分析和优化思路，得到具体的业务需求，即具体问题呈现。

^图2-1

根据价值交换理论，影响价值需求的会有价值交换的两方面，目标系统业务需求输出价值的受益者和解决业务需求的支持者，支持者包含所需的资源或者支持的利益相关者，例如OGV内容的消费用户就是典型受益者，而促使OGV内容生产出来，使用户消费到这一系列内容的系统能够成功的投资人，监管者，合作的文化公司，员工等都是支持者。参考图2-2

^图2-2

在价值需求分析时，支持者更为重要，因为他们决定了目标系统的愿景和范围，确定开发目标系统的约束条件；在业务需求分析阶段，受益者更为重要，他们决定了系统的业务流程和业务场景，但是这些业务场景必须要获得支持者的认可。

在实际价值需求分析中，一般会从两个角度识别利益的相关者：

一个角度通过目标识别利益相关者，从组织架构角度了解组织相关人。从OGV关联组织架构看，从版权合作采购，制作出品，运营，大会员，市场，BI，商业化，媒资内容生产运营，支持部门的财务等部门负责人，分支部门负责人都是价值需求的关键干系人。

另一个角度通过风险识别其他利益相关者，具有一票否决权的评价者的关键干系人，业务负责人，技术实施存在风险的开发团队关键干系人，监管风险相关的法务部门等
这个方面来说，OGV业务所涉及的利益相关者是较多的。

在相对高的层面也会通过商业模式画布看价值需求
作为面向内容创作者（UP主）和内容消费者的内容平台，OGV内容作为其中重要的一部分，OGV内容消费者是平台消费者的一部分，但是在供给端和UGC完全不同的模式。

我们常常会把领域专家，开发团队等组织在一起基于商业模式画布的指导和规范下，通过头脑风暴的方式可以有效的启发和约束思维明确明确价值需求，同时有助于在目标系统的价值需求上达成一致。

参考图2-3

^图2-3

在过往遇到的相当多的需求中，非常的缺少对于需求价值的描述，或者描述的方式言之无物，放之四海而皆准，例如定性描述“提升投放的效率”，“改善用户体验”，这样的目标无法指导、衡量系统的开发和实施。确切的搞清楚和描述价值，另一个层面是为了更加明确问题的影响面，优先、重要程度。

首先建议定量描述，遵循SMART原则，使用具体，准确的数据描述，例如：通过系统自动产出投放图片物料（Attainable），在功能上线后2个月内（Time-based），将OGV内容投放时的图片物料制作效率（Specific），从每月12人天降低到3人天，提升对应渠道投放的及时性，同时做到60%内容可以在特定渠道A的自动投放（Measurable），从而提升投放效率（Relevant）。理论上大多数的需求都是可以找到定量描述的方式衡量价值。

其次，在无法定量衡量的情况下，好可以场景化描述，
后，不建议任何模糊的定性描述，在目前的一些互联网用户端需求价值验证中，无法直接确定价值的情况下，也会大量使用A/B实验等手段进行方案验证，但是这种方式在复杂的业务问题中不一定合适，因为能够开启实验的研发成本过高。

业务需求是实现价值的具体内容，用来清晰地表达利益相关者对于目标系统提出的业务功能要求，这里的需求一定要在用户视角展开，而千万不能受所谓“功能”的影响，将解决方案当作需求。业务需求必须在价值需求的指引下，明确各个利益相关者的前提下，在支持者的帮助下，考虑受益者的目标，思考目标系统应该为受益者提供什么样的服务。

在实际分析业务需求分析过程中通过两个方面看价值和目标：

1. 通过分析业务流程体现流程完整的业务价值

2. 通过一个阶段内满足多个利益相关者的业务目标，达到一个阶段性目标，或者为某个利益相关者提供全方位的服务。

业务流程必须要完整的体现端到端的服务过程，要有因有果。通常情况下，业务流程的起点由一个角色发起服务请求，但是完成整个业务流程，需要多个角色共同参与协作，那么梳理业务流程时必须全方位观察目标系统以及其所在的组织，确定各个角色在流程中应该履行的职责和协作的顺序。

业务流程的发起，有外部用户发起的服务请求，组织内员工发起的请求流程，管理职能发起的服务请求。呈现业务流程直接的方式就是业务流程图，可视化的方式简单清晰表达业务本身运作方式，明确业务规则，以OGV业务为例，用泳道流程图呈现用户，内容提供者，内部运营，平台之间的关系。参考图2-4

^图2-4

这个整体的业务流程涉及到组织内外的各个角色，部门之间的协作，并且不存在主次之分，都是参与流程的协作方。流程中的执行活动都是为了满足终的业务价值，但是执行环节的操作目的和意图都不相同，组织内的一些执行流程对服务请求的发起角色而言，大多是不可见的。一些提供支撑或者管理意图的活动可能会出现在不同的业务流程中，例如流程中的采购活动，也同时出现在公司其他业务中。视频制作和审核对于UGC业务，直播业务也同样需要。从这个角度来说，业务流程不仅需要有端到端的完整性，还需要有边界，职能边界和系统边界。

那么如何识别业务流程？在实际的识别过程中，通常我们会先外后内，先业务后管理。

1. 识别外部引起的主，支，变业务流程，外部服务请求引起的业务流程大多是外部客户和用户，因此先识别这些，参考下图2-5。

2. 内部发起的主，支，变业务流程，例如运营评估流程，授权IP版权流程等参考图2-6。

3. 识别管理流程，管理类的流程一般是管理者为了控制业务开展，规避风险，控制结果，一般会涉及事前预防的管理，事中的审批、规则，事后的分析的报表和数据分析，例如活动预算申请，OGV版权的立项评估，采购合同审批，上线后的剧集内容的播放量，时长，引入的大会员人数等数据分析。

^图2-5

^图2-6

识别了相关的业务流程之后，需要对这些业务流程进行相关的分析和优化，

首先业务流程是有层次的，以图2-4的OGV业务流程图为例，基本上这个流程图的每个节点都是一个复杂的子流程，同时这里的参与方有不同的细分，例如内容提供者包含外部媒体公司，也包含内部的动画制作中心等，运营包含，版权运营，内容运营，媒资运营，大会员，商务，BI等，用户也包括了，大会员用户，普通用户等用户差异，我们这里合并看待是为了有一个能够表达整体业务端到端的流程，如果开始就把这些差异全部表达，这个流程会变的非常的复杂，而无法看到业务流程的全貌。

其次业务流程分析的关键是分析：分工，活动，协作，分支，管理层面的审核，规则，异常。

这里按照分层，业务流程高的组织级流程（图2-4），为了更好说明OGV业务的细节，表达部门间的协作，细化部门级的业务流程呈现图2-4中的视频生产子流程图2-7。

^图2-7

这里OGV视频介质的生产除了OGV事业部的内容运营，媒资，OGV平台，主要需要其他合作部门版权运营，主要的稿件平台，视频云平台的协作完成OGV视频的生产。

根据图2-5，图2-6 提供的分析思路，正常OGV视频生产业务流程是图2-7这样的，那么提供的这样的服务请求有变体流程吗？当前业务确实已经存在，例如：OGV通过和UP主合作对UP主创作视频进行收录，那么这些视频引入OGV剧集的方式和图2-7的流程是截然不同的，除此之外还有，机器发起的针对正片视频生产的高能看点的生产流程，同时机器发起生产的拆条视频的生产流程和图2-7的业务流程都会存在差异，这些都是区别于主服务请求的一些变体服务，篇幅问题这里就不详细展示具体的变体流程。

当然，为了更好服务我们的用户，仍然存在一些支撑的流程，如果图2-7中生产的视频在发布上架之后，视频中的某些，字幕，视频片段存在瑕疵，甚至是错误，那么这个时候，内部OGV媒资需要发起视频换源流程进行视频的重新压制换源，这里就需要我们有清晰的支撑主业务流程的流程来支持视频换源。

业务流程分析产出业务流程图，这个过程中通过不同层次的业务流程的分析识别出主要核心业务流程和变体业务流程，同时兼顾到异常的支撑业务流程。实际实践中，通常只需要对业务流程进行分析，但有时不可避免要对部分的关键流程进行优化，流程信息化之后，有必要对线下手工流程进行适度的优化。

这里针对不同的用户，不同目的发起的业务流程的分析结果，是下一步分析业务场景的重要依据。

对于业务场景，通俗直观的可以认为是为了实现一个业务目的，角色和角色，角色和目标系统之间在特定时间进行的互动行为。

在理解业务需求时，对业务流程进行了分析，优化之后，那么接着需要识别流程中存在哪些和系统相关的业务场景。业务场景是以用户为中心，描述用户的操作行为，体现用户对产品的使用状态。这里分析业务场景的本质是为了了解用户在什么场景下需要系统的支持，为什么要提供这样的系统功能，为判断决策提供依据：实际交付进度要求，系统性能的要求，易用性的要求，部署环境的要求等提供用户场景依据。

通常情况下我们会如何识别业务场景呢，有两种常用的方式：

一. 通过业务流程识别业务场景

通过识别业务流程中的角色和场景，就可以较容易清晰的知道特定角色和角色，角色和系统之间的互动行为，进而知道系统需要提供的服务。

在图2-7中OGV平台提供剧集单集创建和剧集单集上架功能，进而C端多渠道用户才能观看到相应的视频作品内容，同时这里还隐含系统之间的扩展功能，在剧集分集上架时对稿件平台稿件开放。如下图3-1:

在图2-7更细化的业务流程(这里不再展示)中，我们分析到内容运营角色和其他角色互动，以及和系统交互来完成特定的目标，例如，为了在特定时间剧集分集，通过设置定时上架时间，完成内容上架，以达到C端用户可以观看内容，这里通过用例图来表达业务场景。

^图3-1

这里需要特别强调，

1. 详细的某一用例的表达，不能只是体现系统功能，核心要体现实际角色在什么场景下需要这个功能，例如图3-1中，系统提供功能更新剧集分集的发布时间，这个系统功能的一个使用原因：剧集分集延迟播出

2. 在分析场景过程中，会经常出现隐含在系统内部的处理逻辑，比如校验，检查，上面提到的发布上架过程中对稿件平台的稿件开放动作，没有作为用例出现，这个是业务逻辑，从用例抽象角度来说，不应该让角色直接感知，会造成干扰。

3. 在图3-1中有扩展关系的用例，本质上，这些扩展用例可以抽象泛化来表达，但是这么识别和扩展表达地目的也是为了让实际角色更直观感受到场景，抽象泛化会让角色困惑。

在通过业务流程识别了角色和业务场景之后，需要对业务场景进行补充，常见如由时间、状态而触发的业务场景，如图3-1中的定时上架，某个内容因为版权到期的状态变化，导致内容需要进行下架的场景。

二. 对无业务流程业务识别业务场景

通常我们需要回归到业务场景的基本构成来看，业务场景本质体现了，角色（Who）在特定空间（where）的特定时间（when）为了达成一个目标（why）而执行的活动（what），对于无业务流程的业务，我们需要从源头看服务请求，在业务流程识别中图2-5和图2-6中指出，无论是外部，内部，还是管理类的流程都有一个发起源头，对于静态场景，没有流程，只需要通过类似方法，识别源头的服务请求，搞清楚源头角色对于业务场景本质的几个要素是什么，就可以得到业务场景。

在业务场景分析中，我们可以得到多个利益相关者在不同场景的用例，我们也会对不同场景的用例集中去看利益相关者角色的总体产品行为，在用户角色视角清晰看到他们对产品/系统的诉求。

在Eric Evans 的领域驱动设计中，强调要求团队在进行所有的交流是都使用一致的语言，在代码中也是这样。这一 “统一语言(Ubiquitous Language)“被非常重要的强调。

统一语言的一个目的是为了有效沟通，在Eric Evans领域驱动设计的统一语言获取阐述中，通过空中交通监控样例中开发人员和领域专家之间对话逐步提取语言，现实中基本很难行的通，在实际的日常环境中，领域专家角色不明确，对于领域知识的获取，会从业务侧的支持者，产品经理，研发人员多方的直接或者间接的沟通中获取，产品经理和业务利益相关者的访谈，研发人员和产品经理的需求评审等形式中获取，这里面业务利益相关者，产品经理，研发人员都有自己的语言体系，上述的价值需求和业务需求的一些可视化的结果产物（业务流程图/业务用例图），以及分析方式，都是为了在沟通中捕捉到更完整的领域知识，反复确认，不断达成统一语言。

统一语言另一个目的是为了就领域问题，知识达成各个利益相关者的理解一致，好的方式是有可视化的图表，文档描述来确认这些理解，形成统一的认知。例如，在OGV的内容运营侧会提到“厂牌”这样的业务表达，这个概念在产品或者研发侧是完全不知道在表达什么，那么在需求的沟通和确认过程中，明确“厂牌”就是指媒资的制作或者出品的公司品牌“BBC”、“国家地理”、“迪士尼”这类。理想的统一语言是希望做到业务，产品，技术统一表达制作公司/出品公司，但在实际中，我们无法要求业务的表达做出改变，对于“厂牌”的通俗表达，在技术代码中又不太能明确表达，在反复确认中，统一认识，在统一语言文档中，指明“厂牌”和制作公司/出品公司是同一业务含义。

统一语言的使用和建立贯穿问题探索，需求明确，到模型分析，设计，代码的编写，建议在模型和代码之间以及在统一语言和代码之间做映射。这非常有帮助，它会让代码更可读，让模型得到完美实现。

什么是领域，为什么要有子领域，这里只通俗谈自己的理解，领域就是知识的集合，比如提到财务会计领域，自然会联系到总账，利润，会计科目，固定资产等，这些都是特定财务领域知识。

在OGV业务的整个问题空间中，涉及版权，媒资，剧集，视频，社区，风控，投放，营销等知识。通过需求分析，将业务流程和业务场景，可视化的呈现在团队面前，其实问题本身已经变的清晰。面临OGV整体的问题空间时,业务复杂度比较高，为了降低关注的业务复杂度，同时让开发团队更好把握问题空间，不至于迷失在业务细节中，我们划分了子领域。

在《实现领域驱动设计》和领域驱动相关社区中都有一些说明，子领域是对问题的分解，对子领域区分：核心子领域，通用子领域，支撑子领域，也是为了区分整个问题空间里面的重要问题和次要问题，通过划分子领域，让相关人员对问题空间本身有共同的理解，也能确定不同业务的优先级，每个对应子领域该安排有能力的团队成员来开发，还是次能力团队成员来开发。一般情况下通过判断业务价值的大小就可以确认哪些业务属于核心子领域（核心问题），通用子领域（没有领域个性），支撑子领域（辅助完成解决核心问题），这里主要看上面价值需求分析的结果。

那如何识别和区分子领域。通常从以下几个方面：

1. 通过业务职能划分，如果系统运用于企业的生产，运营，管理，那么与系统有关的职能部门职责会影响子领域划分，职能部门的组织结构和子领域有一定的映射关系，结合图2-7的业务流程，同时在需求分析中也比较容易得到OGV业务的组织结构，OGV媒资制作，OGV内容运营，版权运营，这些职能角色或者部门在内容生产制作，内容运营，投放运营方面有对应的职能分工。

2. 通过业务产品划分，典型的就是企业的产品线或者业务线，比如B站的漫画业务，电商业务，游戏业务等，这些业务结构可以作为划分子领域的参考。

3. 通过业务流程环节划分，如果考虑这个因素，那么确定核心业务全景流程，就会非常重要，根据业务流程的时间节点划分多个业务环节，如图2-4流程，一个可供用户观看的作品的供应和用户观看作品的流程就是其中的一个核心业务流程，该业务流程存在多个时间节点环节，内容引入过程涉及的评估，采购，内容生产涉及到剧集，媒资，视频等，运营宣发投放，用户消费，社区管理，这些环节节点是考虑子领域划分的重要依据。

4. 通过业务概念进行识别划分，这个就比较玄学了，主要依靠对问题的深刻分析理解和直觉。对于OGV的业务可以浮现出来的业务概念：版权，剧集，媒资，片单，系列，视频，稿件，弹幕，评论等，根据这些概念找到与之对应的管理这些业务概念的子领域，例如对稿件管理的稿件平台。

虽然我们可以从上述的一些角度分析划分子领域，但是这个过程还是存在很多经验因素，同时在讨论过程中还要规避很多容易陷入技术实现的陷阱。作为技术角色参与这个过程一定要分清此时的目的是为了拆分，确认问题领域，切勿考虑如何解，例如我们知道OGV业务中涉及到弹幕，评论，那么在解空间中我们考虑是否要建立弹幕管理，评论管理，这个实际的建立是直接委托给B站内部UGC业务同样业务属性的弹幕中心，还是需要独立处理一些OGV业务特性，甚至对于一些业务域可以直接购买外部系统。如果一些技术人员无法避免谈过多技术实现，可以在这个分析阶段将技术人员排除在外。

结合上述的1，3的业务职能部门的具体职能和核心业务流程的流程环节分析，再结合4方法的业务概念罗列，得出下图4-1是OGV业务核心相关的子领域映射图：

^图4-1

在图4-1中虚线分割部分是子领域，实线分割为限界上下文，原则上识别出来的每个子域只对应一个问题，子域之间是相互独立的，没有交叉，没有包含关系。图4-1中的子领域是在整个OGV业务的角度进行识别划分，在这之外还存在一些非强业务相关的推送通知，流程管理，认证验权等通用子领域。理论上子领域仍然可以被分解，例如我们通过对不同内容运营部门的不同角色对内容的运营阶段的需要，将剧集子领域又被分解为剧集内容，排播，策略规则，每个细分的子领域又对应一个该领域内的特定问题。

除了进行子领域的识别和划分，在问题阶段要明确每个子领域核心要解决的问题是什么，例如：剧集的领域是作为OGV内容载体供用户消费，需要解决内容的表达载体，管理，排播，运营等问题。在剧集的细分子领域中：

1.剧集内容的表达，就是要解决剧集，分集，片单的内容关系，以及基于内容的上下架等各种管理，以及用户的消费。

2.细分的排播子领域：主要是用来解决剧集内容的排播计划，一方面让支撑运营管理内容的播放计划，同时让用户可以消费到海量内容的播放计划。

3.策略规则的子领域：主要是面对运营支撑者解决剧集内容在播放控制，分发控制，付费控制等多个业务维度的运营问题。

当我们在定位一个子领域时，会出现其他业务内也存在这样的问题，例如：版权，OGV业务面临版权问题，bilibili的其他业务音乐，漫画等也面临版权问题，此时在另一个的层面，企业维度来看，这个对于OGV来说的版权子领域，在企业多业务角度，版权领域的定位就会发生变化，其要解决的就不仅仅是OGV业务的版权问题，并且随着外部环境变化（政策，行业对版权的规范性变化），领域的重要程度也可能变更，但是并不改变子领域在价值归属，版权领域作为支撑子领域的价值判断。

在看待问题域的子领域时不考虑实现问题，例如图4-1中的稿件，用户，弹幕，评论对于OGV业务而言是核心业务，但是这些子领域在实际中已经有其他非OGV业务的支撑人员和系统可以解决这些领域的问题。

这篇文章主要介绍领域驱动设计解决软件核心复杂性的问题空间分析过程和方法，通过利益相关者和商业模式画布的价值需求分析，业务流程识别、业务场景识别的业务需求分析方法，分析问题空间的业务问题，根据价值需求和业务需求的分析输出的可视化结果初步得到统一语言和子领域，达到对复杂软件开发的问题规模的分解。更通俗简单的说，只是在明确业务问题和简化业务问题。

后续会进一步介绍我们根据领域驱动设计理论和社区中领域驱动架构的演进变化，在实际架构中所做的调整，来分析领域驱动设计的架构模式对结构复杂度的解决方式，还会介绍在子领域内对具体的子领域问题的领域设计和编码，以及分析模式在具体的问题分析中的应用。