在社会技术系统中调整有界上下文，以支持业务价值流。当您能够了解业务的价值流时，请在DDD战略层面上使用它们。
例如，在一家在线销售实物商品的电子商务公司中，体现业务价值流的活动包括：
- （根据物理位置或从远程）获取要出售的物品
- 描述其物理细节（颜色，质量，图片和其他有助于其投放市场的信息）
- 评估和交互以处理库存数量
- 为客户创建和管理机制，以浏览目录，下订单和付款，调度项目
同时，有一个营销系统来放置广告，完成销售后，将有一些客户服务功能。
以上所有都是价值流的活动。它们可以并行发生，并且流可能有些复杂，但是它们可以彼此独立进行。但是，它们具有依赖性。例如，负责让客户下订单的系统显然需要了解可用物品的库存-它们是相互关联的。
上下文语境
“如果无法描述您在一个流程中正在做什么，那么您将不知道自己在做什么。” -威廉·爱德华兹·戴明
关于价值流和价值流映射的文献很多，但是我认为要理解的关键概念并没有得到更多的详细说明。从这个角度来看，精益价值流的概念是组织为了为客户，利益相关者或最终用户产生总体结果而进行的一系列活动的示意图。流程的活动是独立的，但相互联系；这是复杂系统的特性之一。每个活动在自治中执行不同的任务，但会将信息反馈给系统的其他部分，以使价值链进入下一阶段。
为了使组织的整体熵得到控制，企业必须正确地将这些活动分离并分组为独立但相互关联的子系统，并优化其通信。这是关键点。在领域驱动设计的世界中，这些子系统称为“ 有界上下文”。
由于有界上下文是高级模块，因此它们之间还应该特别关注通讯。此外，鉴于要达成良好的理解，我们应该将焦点移至外部系统（如罗素·阿科夫（Russell Ackoff）所述），这解释了为什么理解价值流以在有界上下文之间设计最佳交互流很重要。
系统的这种逻辑、高级视图比内部结构更重要，因为它是做正确的事情的关键。在这里，关键是要在它们的独立性和相互关系之间找到完美的平衡，并决定如何分割它们。应该将哪些子任务组合在一起以形成一个有界的上下文，那么什么标准衡量应该独立存在呢？
答案是，这取决于整体情况–抱歉，这里也没有灵丹妙药！但是我们有一些原则可以帮助您进行决策的归纳过程。例如，我们可以在此处看到与凝聚力和耦合力相同的作用力：
- 凝聚力太强：将每个任务都放在一个大范围的上下文中将意味着纠结系统，使其难以更改和扩展，类似于上帝和发散性需要更改代码的坏味道。
- 耦合过多：将每个任务拆分为自己的有界上下文意味着将复杂性移到它们之间的通信上，从而产生大量依赖关系。此外，实现独立性的方法在SOA环境中并非免费的。必须创建，部署，维护和监视基础结构边界。
“您必须选择在哪里支付复杂性的代价。因为DDD旨在降低软件的复杂性，所以结果是您要为维护重复的模型和可能的重复数据付出代价。” -埃里克·埃文斯（Eric Evans） |
