流体ps_流体设计或面向功能的设计

流体ps

“功能性”是给定需求的实现，它是用户或系统（称为参与者）必须执行的一系列功能步骤，以实现需求描述的结果。 例如，需求可以定义为“允许计划者创建发货”。 在一种可能的设计中，一个或多个参与者可能需要完成以下功能步骤：

• “定义组织管理员将订单与计划者相关联的规则”
• “由计划者制定一套规则以将订单合并为一批货物”
• “系统根据组织规则自动将订单添加到用户的工作空间”
• “运行计划员设置的规则以通过系统创建发货”

由各种参与者共同完成的这套动作被称为产品的“功能”。 设计上述功能的典型步骤从数据和数据库开始。 标识了新的数据库表，例如与订单和计划程序工作区相关联的“规则”表，用于存储已设置的规则，“工作区”表，用于存储装运的“装运”表以及与装运相关的表等上。 然后将它们适当地标准化。 跨功能共享数据库表所需的列（例如，在上述组织，用户和订单中）被标识，合并和修改以存储新数据。 例如在上面的规则表中识别和修改新表和现有表之间的关联，以进行识别。 完成后，接下来的步骤是对DO和DTO或DAO进行编码，以对这些表执行CRUD。 然后，编写将所有这些DTO / DAO / DO绑定在一起的“处理器bean”，以将所有CRUD操作纳入基于功能设计的逻辑实现中。 以后或可能并行地考虑和设计用户交互。 有时，用户交互仅被视为数据库表中数据的转换，以直接在UI屏幕上呈现。 我称这种设计为“面向数据库的设计” 。 就像其他所有内容一样，这样的设计过程也有其自身的缺点。 在这种设计中以各种形式抬起头的潜在缺点是：“思维的方向是使技术方面的功能可视化，而不是功能方面的可视化”。 看一下一些缺点：

通常，在几乎所有此类设计中，“用户”都会受到数据库表设计中的限制。 虽然绝对有可能以多种方式组合表中的数据以使用户与表设计脱钩，但我们发现我们的想法受到了设计数据拆分的限制。 因此，用于与其他系统交互的所有屏幕或API的方向通常趋向于模拟相同的拆分。 数据库表可以以任何方式设计，从频谱一端的高度规范化，高度限制性，高度验证的非灵活关系数据设计到存储在noSQL数据库中的高度灵活，非规范化，非限制性，非相关数据。另一端。 需要注意的重要一点是，无论如何存储数据，数据库设计都只是一种技术实现， 可以满足所有应用程序的附带要求 ，即具有持久的业务数据可用于跨功能或业务交易。 应该记住， 业务交易是产品的核心，而不是数据库表。

核心劣势的影响在模块化中被巧妙地看到，并且从未被认为是劣势。 模块化是行业内每个人松散使用的非常普遍的术语，但是，对于模块化的面向技术思维方式的含义尚不清楚。 下图简洁地说明了此缺点的影响（通常用于解释MVP）。

第一个图表系列展示了仅专注于技术模块化的影响。 进行面向数据库的设计会消除设计的“功能”。 通过消除这一点， 它使设计人员可以非理性地将产品视为数学概率或排列和组合 ，从而能够将功能划分为各个维度。

再次进行创建装运。 需要设置规则来确定订单是否属于用户的工作空间，并且需要定义规则来确定订单是否可以与其他订单合并以创建装运。 这里应该注意的是，虽然这两个都是规则，但在功能上却完全不同。 在第一种情况下，规则纯粹是在与订单关联的属性上运行的表达式。 因此，可以说order.origin.region是区域1，order.destination.region是区域2，与计划者1相关联，或者可以说orderline.product是产品1，然后将其与计划者1相关联，依此类推。 但是，在第二种情况下，需要的是在合并或拆分之前需要评估的一系列“ if-else”规则并运行逻辑。 因此，如果订单从相同的起点1到达相同的目的地1，则可能会有一组规则以这种方式运行，如果订单数量未超过该路线中的可用集装箱尺寸，则合并。 这不是对象上的表达式求值器，而是一个设置的if-else规则引擎，该引擎需要应用于各种对象，例如订单，路线，容器等。

当完成面向数据库的设计时，考虑到思想是面向技术分组的，我们倾向于说规则是一个通用的对象，规则框架与之配合使用，因此，对于这两个领域，都需要一个“规则框架”。场景。 因此，我们最终遇到了这样一种情况：第一种情况必须采用第二种情况下不必要的代码版本，或者第二种情况必须受到第一种情况的限制。 我们受到代码重用，模块化编码，不再重复编码的自身限制，因为这是维护的噩梦，等等。 尽管边界是好的，但现在是时候问问自己，为了维持这些边界我们会牺牲什么，并且这些边界是否不必要地限制了正确的模块化？ 其他大多数限制，例如我如何仅缩放一个功能而不是缩放所有功能，一组嵌入的“ If”语句来定义基于许可证的功能和功能的可用性等，在我们谈论面向技术数据库的那一刻就引入了设计。

流体设计

上图中的第二个图系列提出了流体设计的概念。 流体设计是面向功能的设计。 在这里，设计首先要确定形成给定功能的要素。 接下来使用这些拆分功能，通过剥离或存根功能来识别单个核心功能，可以将其视为核心功能的增强。 这为我们提供了开始实施的基本功能。 使用此框架，我们可以识别参与者交互，业务对象和必须在该业务对象上执行以进行参与者交互的交易。 要继续，我们选择下一个功能并将其剥离，直到具有当前实现的下一个一致功能可用，然后设计并实现该功能，然后继续。

应当指出，与从设计中完全删除技术设计元素相反，这种设计是透视图的变化。 在以这种方式进行设计时，假设数据库框架，日志记录框架，集成框架，身份验证框架等以及相关的技术框架是偶然的，并且已经可以作为某些基础平台的一部分使用具体定义的方法来使用它们 。 无论如何，大多数现有产品都是这种情况。 如果是新产品，这些框架通常以库的形式提供，可以提取和使用这些库，而无需重新发明轮子。

这里要注意的一点是，设计师被迫专注于功能方面以及技术方面。 该设计被视为参与者交互，业务对象和业务交易，随着实现的进行而递归地进行了改进。 因此，在任何给定的时间点，都存在业务交易的工作版本，而不是任何工作代码。

为了查看例如，从上面的创建装运中，进行设计的步骤如下。 首先是识别功能。 确定的可能功能包括：

1. 规划人员创建工作区
2. 将订单添加到工作区
3. 根据属于工作空间的一组订单创建货件
4. 基于规则向工作区添加订单
5. 基于规则的货运创建

接下来是从这些功能中识别核心交易。 可以将其标识为创建工作区，添加订单，从工作区中的订单创建货件。 所有其他功能只是此核心功能的附加组件。 接下来，我们确定我们要如何实现参与者交互以使此核心事务正常运行。 一种可能的顺序是，步骤1：用户创建一个指定名称的工作区，步骤2：随着订单的到来，我们将所有订单添加到任何用户创建的所有工作区中，步骤3：用户选择订单并手动单击创建货件按钮以创建货件。 第4步：创建装运，并将订单状态更改为计划，并从存在的所有工作区中将其删除。因此，这成为第一个实施的精简版本。

现在，我们确定核心交易的业务对象。 可能的对象是工作区，订单和装运。 订单应该已经存在于系统中，我们唯一必须添加到订单中的可能是“属于工作空间”属性。 应该注意的是，我们标识的是业务对象及其属性，而不是数据库表。 从这些业务对象创建的数据库表需要推入平台的数据库存储层。 最简单的实现可以为创建的每个业务POJO对象创建一个表。 更为复杂的版本可以根据数据大小和数据关系将对象拆分为多个表。 甚至更简单的实现也可以将这些对象存储为纯序列化的Blob，并根据需要检索它们以构造对象。 但是，重申一下，数据存储是偶然的，需要以这种方式进行处理。

一旦确定了对象，我们就会根据已定义的参与者交互来确定需要对这些对象进行的操作。 必须创建工作区，需要将订单添加到工作区，并需要根据工作区中的订单创建发货。 我们为每个这些公认的动作定义API。 公开这些API的方式是集成框架的责任，应该这样保留，可能是该层将JSON公开为API。 然后，我们确定要执行的逻辑以及何时需要触发这些API。 这导致我们设计和编写两个屏幕，第一个屏幕创建工作空间，第二个屏幕显示工作空间中的订单并根据所选订单创建发货，编写两个业务对象，修改一个业务对象，定义三个API以及它们的逻辑和一个API进行修改，以便在工作区进入系统时向其添加命令。

这里的重点是，当我们实现这些功能时，我们正在使用功能完整的交易版本进行演示。 模块化基于功能和特征是自动的，核心特征进入一个模块，随着功能的添加，可以将它们拆分为其他模块，或者根据分析将其添加到同一模块。 扩展，记录，调试一切都以功能为导向，因此可以轻松地将其与正在执行的业务交易联系起来。

当我们开始使用功能扩展功能时，设计中的流畅性就变得显而易见。 让我们看一下与功能添加有关的规则。 设置规则以将订单添加到工作区。 我们开始将此功能简化为最低限度的实现，然后发现我们在这里提出了正确的问题，例如“在向工作空间添加订单方面有哪些实际字段？ 我们可能会发现典型的计划人员可以处理从一个地区到另一个地区的订单，仅此而已。 因此，我们只执行基于区域的规则来添加订单。 这使我们可以向Location业务对象添加功能，以将其分类为区域，并使用这些区域专门向工作区添加订单。 在这里，我们实现了非常具体的逻辑，没有涉及任何规则框架。 其他功能会根据功能分析（而不是技术分析）自动扩展。

从与规则框架相关的设计开始时，我们倾向于说“为什么限制用户，他们可以使用订单中的任何字段来评估表达式以将订单添加到工作区”。 从技术上讲，这似乎易于实现并处理用户所需的所有情况，但这是典型的数学排列和组合实现，不必要地增加了产品的复杂性，却没有为客户提供任何额外的有价值的产品功能。 另外，我们引入了一个未使用的复杂规则框架代码，该功能甚至不需要。

流体设计是可延展设计。 流畅的设计肯定会引入重复的代码，可能会引入重复的错误。 但是，这些都是可以解决的问题，可以通过正确的平台定义和选择来解决。 与广泛的编码和测试相反，可以将技术细节推送到平台，并可以简化功能实现以进行正确的设计。

翻译自: https://www.javacodegeeks.com/2019/04/fluid-designs-functionality-oriented-designs.html

流体ps