从基于CRUD（创建，读取，更新删除）的UI转移到基于任务的UI，意味着创建一个使用户任务明确的用户界面。任务（或动作，命令）是一种指导用户执行针对给定状态或工作流可以采取的特定动作的方法。当按操作细分时，您可以开始查看边界可能在哪里，这可以帮助将实体划分为多个边界。
增删改查
对于此示例，我使用的产品实体包含我们的应用程序中使用的各种属性。
所有属性应该是不言自明的。如果我们要创建一个基于CRUD的UI，我们将简单地拥有一个页面/表单，该页面/表单允许用户设置所有各种属性。
当您单击保存按钮时，所有数据都将发送到服务器，并且整个实体都将更新。
那么CRUD有什么问题呢？
在某些情况下，创建基于CRUD的UI可能没有任何问题。但是，当您开始根据用户正在更改的数据来推断用户的意图时，最好是改用基于任务的UI。
在上面的基于CRUD的UI中，如果用户将价格从$ 85更改为$ 80，然后单击“保存”，他们是否只是在更改价格？那是他们的意图吗？还是他们打算降价？您系统的其他哪些部分需要知道这种情况？
您能告知“愿望清单”中包含该产品的客户价格现在更低了吗？
基于CRUD的UI不能捕获用户的意图。这不是明确的。您需要得出用户意图是什么。在基于任务的UI中，您要使用户的操作明确。使隐式显式。
边界
构建基于任务的UI的第一步是了解实体上的哪些属性会一起更改或相关
具有名称和描述的红色（顶部）框可以一起更改，也可以独立更改。这两个后面可能没有太多的行为/任务，因此它们可能只是CRUD。
带有价格，待售和免费送货的紫色（左下）框可能用于销售目的。
绿色（中间下部）框具有“成本”，这是来自供应商或制造商的成本。它根本与销售价格无关。
黄色的框（右下）具有“数量”，即“仓库中的现有数量”。它与成本或销售价格无关。
基于任务的用户界面
如果您使用基于CRUD的UI并将每个框分隔到其各自的边界中，则可以开始询问以下问题：用户在更改这些字段时的意图是什么。他们为什么要改变它们？不同的用户/角色可能对不同的数据有兴趣。
SKU，名称，描述可能归目录服务/边界所有。本质上，这可能完全是CRUD。但是，价格可能归销售所有。采购将拥有成本，而现有数量将由仓库拥有。
从用户/角色的角度来看，当他们想要在该边界内更改数据时，他们试图执行哪些任务。
现在我们可以看到Sales可以增加价格或减少价格。如果我们想提高价格，我们将提供针对特定任务/命令的功能。
如果仓库对产品进行库存盘点，并确定货架上的数量不如系统所说的那么多，那么他们将进行库存调整。他们不仅在更新QuantityOnHand值，而且还出于特定原因显式更改要添加到QuantityOnHand或从中删除的数量。
边界
我们不仅明确定义了用户的任务/动作是什么，而且还定义了边界。产品的概念可以存在于多个边界/服务中。您不需要将一个实体放在一个地方，它包含整个系统的所有数据。