数学建模任务定价_商业交易建模– 1（用于SaaS定价）

数学建模任务定价

在博客“ 将服务器应用程序转换为云应用程序 ”中，我谈到了业务功能所需的更改，以将应用程序转换为云应用程序。 在本系列中，我想介绍实现这些用例所需的体系结构更改。

需要重新设计价格

从定价用例开始，可以通过多种方式进行定价。 一些示例是：

1. 每笔业务交易
2. 根据不同业务交易的最终状态
3. 按使用方式（使用特定业务交易的活跃用户数）
4. 用户块，业务交易块等。

例如，在petstore蓝图中，“ Buy Pets”可以被视为涉及以下步骤的商业交易：

1. 搜索宠物并将其添加到购物车
2. 查看购物车
3. 注册并登录系统
4. 创建订单
5. 支付订单

在SaaS模型中，可以以不同的方式为该业务交易定价。 例如，可以为“创建但未付费的购物车”提供较低的价格，而“导致付款的购物车”可以定价为更高。 这使SaaS客户（例如，宠物店所有者）可以轻松跟踪他们的ROI。 它还允许基于业务交易的复杂性进行定价，而业务复杂性则由业务原因支持以更高或更低的价格。 例如，由于集成到支付网关中，涉及“订单支付”的业务交易成本更高。

为了能够以这种方式进行定价，系统应识别业务交易 ， 业务交易的状态，使用业务交易的用户等。 此外，还应该认识到，SaaS定价未经测试，没有关于最佳定价方式或最佳方式的数据。 定价必须是试验性的，产品的架构应易于收集数据以帮助分析利润。

MVC之类的标准体系结构面向技术实施和代码模块化。 业务交易只是分布在代码中的抽象概念而存在。 例如，在petstore应用程序中，“ Buy Pets”业务交易被建模为组件“ Shopping Cart”，“ Customer”，“ Inventory”，并使用控制器将它们捆绑在一起，如下所示：

在这里，只能通过跟踪控制器，事件，EJB和其他代码中的代码来理解业务交易。 在此实现中，存在业务交易的所有元素，但它们隐藏在代码的混淆之下，不能用于轻松实现业务交易定价。 自定义报告必须基于对代码的理解来生成。 但是这些报告并没有带来执行业务交易所涉及的复杂性，例如，知道在支付订单之前已经提出了多少个请求。

不能与可以调整和通用化定价模块的现有系统一起实施独立的模块管理。 定价模块的实现必须被编码到特定于不同业务交易的系统中。 这使得尝试定价模型来决定最佳定价变得很麻烦。 所需要的是一种可以以通用方式对任何业务交易进行建模的体系结构。 该模型需要具有必要的要素，以便能够提供标准需求的SaaS用例。

定义业务交易并重新架构

我们可以将业务交易定义为发生在一个或多个业务数据上的一组业务事件，这些业务事件会转换当前或相关业务数据的状态。 业务数据的状态是与业务数据关联的一组属性。

例如，在“购买宠物”业务交易中，我们可以识别涉及的4个主要业务数据（宠物或产品，购物车，订单和付款）。 可以将所有功能组织为在此组业务数据上发生的业务事件。 例如，搜索宠物，创建购物车，从购物车中添加宠物或从中删除宠物，结帐购物车，为订单付款是发生在产品，购物车和订单对象上的业务事件。 这些对象已经存在于任何MVC架构实现中，但并非以此方式组织。 因此，我们应该能够重新组织petstore实现的代码，如下所示，其中包括一些附加功能，即将事件也存储到数据库中：

定义业务交易的优点

一旦以这种方式重新定义了架构，我们就会发现它具有许多优势。 主要优势在于，我们已强制使用系统中某些可识别的对象（即业务事件，业务数据和业务数据状态）对业务交易进行建模。

从开始状态的业务数据（此处为购物车）到业务数据的结束状态（此处为付款），按时间顺序跟踪事件，可以在系统和数据库中表示出可识别的通用业务交易。

这使我们能够针对SaaS用例所需的业务交易实施通用模块。 例如，我们可以计算发生的事件的数量，未完成的业务数据的数量，完成整个交易的业务数据的数量，完成业务交易所需的时间等等。 收集的这些信息有助于我们提供定价，发票，计费等模块的信息，这些模块可以全局更改而不会影响单个交易。

SMART以此业务交易定义概念为基础，提供了一个容器，该容器提供了通用的模块，用于开箱即用地定价，开票和开票。

参考： Reflections博客上的JCG合作伙伴 Raji Sankar提供的业务交易建模– 1（用于SaaS定价） 。

翻译自: https://www.javacodegeeks.com/2014/01/modeling-business-transactions-1-for-saas-pricing.html

数学建模任务定价