Questions tagged «business-rules»

我正在考虑构建一个应用程序，该应用程序的核心是数千个if ... then ... else语句。该应用程序的目的是能够预测奶牛在任何景观中如何移动。他们受到太阳，风，食物来源，突发事件等的影响。 如何管理这样的应用程序？我想象在经过数百个IF语句之后，程序将如何响应并调试导致某种反应的结果将意味着每次必须遍历整个IF语句树，这将是无法预测的好。 我已经阅读了一些有关规则引擎的内容，但是我看不到它们如何克服这种复杂性。

214 design  design-patterns  business-rules  prolog  logic-programming 

我参与过一些项目，其中大多数业务逻辑是在数据库上实现的（主要是通过存储过程）。另一方面，我从其他程序员那里听说这是一个不好的做法（“那里有数据库来存储数据。其余的则由应用程序来完成”）。 通常，哪种方法更好？ 我能想到的在数据库中实现业务逻辑的优点是： 集中业务逻辑； 应用程序类型，编程语言，操作系统等的独立性； 数据库不太容易进行技术移植或大型重构（AFAIK）； 无需重新进行应用程序技术迁移（例如：.NET到Java，Perl到Python等）。 缺点： 由于缺乏面向应用程序的语言所提供的库和语言构造，SQL对于业务逻辑编程而言效率较低，并且更为复杂。 通过库更难（如果可能的话）重用代码； 生产效率较低的IDE。 注意：我正在谈论的数据库是关系型，流行的数据库，例如SQL Server，Oracle，MySql等。 谢谢！

107 database  application-design  business-logic  business-rules 

我听说人们经常在工作中和在线上谈论业务逻辑，并且我已经在此站点上阅读了一些有关它的问题，但是这个词对我来说仍然没有多大意义。例如，以下是我经常看到的一些（释义）语句： “业务逻辑是程序中编码实际业务规则的部分。” 我读过的大多数定义都是这样的循环定义。 “业务逻辑是您的特定应用程序所独有的一切。” 我不认为这与“您的特定应用程序不过是业务逻辑”有什么不同，除非我们不小心重新发明了一些轮子，可以使用现有的第三方软件。因此，问题标题。 “在数据访问层上方和GUI层下方应该有一个业务逻辑层。” 在我编写的代码中，数据库访问者必须知道他们应该访问什么数据，UI代码必须知道很多关于其显示内容的信息才能正确显示，这之间没有任何实际要做的事情。除了在客户端和服务器之间传递数据Blob之外，还有这两个地方。那么，实际上应该放入业务逻辑层的内容是什么？ “业务逻辑应与表示逻辑分开。” 我们收到的大多数功能请求都是出于业务原因更改展示逻辑。如果业务规则之一是默认情况下以32位符号显示美国政府债券价格（同时还为用户提供配置UI的功能），则表示逻辑至少需要知道该规则存在（如果未完全实现）。而且，UX设计的主要部分似乎是帮助用户了解我们的软件试图实现的业务规则。 我是否有可能实际上只在一个只包含业务逻辑的团队中工作，而所有非业务逻辑都由其他团队来完成？还是“业务逻辑”作为一个单独实体的整个概念仅适用于某些应用程序或体系结构？ 为了使答案更具体：假设您必须重新实现Domino的Pizza应用程序。什么是业务逻辑，该应用程序的非业务逻辑是什么？以及如何在不将大多数披萨信息渗入数据访问和表示层的情况下，将披萨订购业务逻辑放入其自己的代码“层”中？ 更新：我得出的结论是，我的团队可能正在执行90％的UI代码，并且您所称的大多数（但不是全部）业务逻辑都来自其他团队或公司。基本上，我们的应用程序是用于监视财务数据以及几乎所有功能都是用户自定义其所见以及所见方式的方式。没有进行买卖（尽管我们与公司的其他应用程序进行了一些集成），并且实际数据由大量外部资源提供。但是我们确实允许用户执行诸如将其“监视器”的副本发送给其他用户之类的事情，因此我们处理方式的详细信息可能符合业务逻辑。实际上，目前有一个移动应用程序正在与我们的一些后端代码进行对话，并且我确切地知道我希望在理想的世界中与我们的UI共享前端代码的哪一部分（基本上是准MVC中的M），因此我猜这就是我们的BLL。 我接受user61852的回答，因为它使我对“业务逻辑”指的是和不指的有更具体的了解。

25 architecture  business-logic  business-rules 

行为驱动的开发及其标志性的“ Given-When-Then”场景语法最近被大肆宣传，因为它有可能用作软件功能评估的边界对象。 我绝对同意，Gherkin或您喜欢的任何功能定义脚本都是商业可读的 DSL，并且已经提供了这样的价值。 但是，我不同意它是非程序员可写的（就像Martin Fowler一样）。 有人对非程序员编写的场景，然后由开发人员提供的场景有说明吗？ 如果确实对缺乏可写性达成了共识，那么您是否会看到一种工具的问题，该工具可以从实际测试中生成业务可读的场景，而不是从场景开始并对其进行检测。 更新：关于“场景生成器”工具，它当然不会神奇地猜测业务语言;）但是，就像我们当前使用正则表达式匹配器以自顶向下的方法（在抽象维度上）创建测试一样，我们可以使用字符串构建器以自下而上的方式创建方案。 “仅给出想法”示例： Given I am on page ${test.currentPage.name} And I click on element ${test.currentAction.element} …

24 documentation  bdd  documentation-generation  business-rules 

我是编程的新手（我是行业的机械工程师），并且在停机期间正在开发一个小程序，该程序将根据工厂周围各个人员的输入生成一个（solidworks）零件。 仅基于少量输入（准确地说是6个），我需要进行数百个API调用，每个API调用最多可以包含十二个参数。所有这些都是我在采访处理零件的每个人之后收集的一组规则所产生的。我的代码的规则和参数部分为250行，并且还在不断增加。 那么，保持我的代码可读性和可管理性的最佳方法是什么？如何分隔我所有的幻数，所有规则，算法和代码的程序部分？如何处理非常冗长而细致的API？ 我的主要目标是能够在没有我输入的情况下将我的消息传递给某人，并让他们了解我在做什么。

21 api  readability  business-rules 

这是我在SO上问过的一个问题，但在这里可能会得到更好的讨论... 在我工作的地方，我们已经在这个问题上来回多次，正在寻找健全性检查。问题是：业务对象应该是数据容器（更像DTO），还是应该包含可以对该对象执行某些功能的逻辑。 示例-以一个客户对象为例，它可能包含一些通用属性（名称，ID等），该客户对象是否还应包含函数（保存，计算等）？ 一条推理路线说将对象与功能（单一责任主体）分开，并将功能放在业务逻辑层或对象中。 另一道理说，不，如果我有一个客户对象，我只想调用Customer.Save并完成它。如果使用该对象，为什么需要了解另一个类来节省客户？ 我们的最后两个项目已将对象与功能分开，但是关于新项目的争论再次出现。 哪个更有意义，为什么？

19 business-logic  business-rules 

我知道这很昂贵，但是（IMO）我认为这是一个很好的做法。我说的是这样的规则，例如，如果您不是销售人员，您将无法保存发票。 另一种方法是使对象具有状态或类似状态 还有其他方法吗？你怎么看这件事？

16 idioms  business-logic  business-rules  rules-and-constraints 

我正在研究干净的软件，因此，我极大地重新思考了如何设计和编写软件的大量方法。 不过，我仍在努力处理业务规则，例如“保存某些项目的更新，首先加载我有权查看/编辑的所有项目列表，确认该项目在列表中，并且该商品类别当前未被锁定（以及其他规则等）。”，因为这是（复杂但非典型的）业务规则，因此应在应用程序域中进行处理，而不是将业务逻辑推送到db / persistence层。 但是在我看来，为了有效地检查这些条件，通常最好使用精心设计的数据库查询来最好地处理它，而不是将所有数据加载到应用程序域中... 如果不进行过早的优化，有什么推荐的方法或鲍勃叔叔的文章处理这个问题？还是他会说“在域中进行验证，直到出现问题”？ 除了最基本的用例之外，我真的在努力寻找任何好的示例/样本。 更新： 大家好，谢谢您的答复。我应该更清楚一些，我已经写了很长时间（主要是Web应用程序）软件，并且肯定已经经历并同意您共同描述的所有主题（通过后端验证，一般不信任客户端数据仅在需要时才追求原始效率，但是在可用时承认db工具的优势，等等），并且已经经历了开发人员学习生命周期的“全部整合”以“构建具有N层应用程序的大型胖控制器”代码趋势，现在真的很喜欢研究干净/单一责任的样式等，这主要是由于最近有一些项目随着项目的发展以及对客户的进一步要求逐渐演变为笨拙且分布广泛的业务规则。 特别是，我在构建REST的API面向客户和内部使用功能的背景下，看着清新的风格建筑，其中许多业务规则可能是多比基本上你在网上看到每一个例子更复杂（甚至由Clean / Hex体系结构专家自己完成）。 所以我想我真的是在问（并且没有清楚地说出）Clean和REST api会如何放置在一起，这些天您看到的大多数MVC东西都带有传入的请求验证器（例如.NET中的FluentValidation库），但是其中许多我的“验证”规则不是“这是少于50个字符的字符串”，而是更多的，“如果某个相关对象当前已被Team X锁定，则该调用此用户案例/交互者的用户可以对数据集执行此操作吗？直到本月下旬，等等”。。。那些涉及深层次的验证，其中适用于业务域对象和域规则的数量。 我是否应该将这些规则分解为特定类型的Validator-object类型，以与每个用例交互器一起使用（受FluentValidator项目的启发，但涉及更多的业务逻辑和数据访问），我是否应该将验证视为类似于Gateway，我应该将那些验证放入网关（我认为这是错误的）等。 作为参考，我会去像几篇文章这样，但马蒂亚不讨论验证了。 但是我想我的问题的简短答案很像我接受的答案：“这绝非易事，要视情况而定”。

13 clean-code  domain-model  validation  business-rules 

现在的情况 我们正在微服务架构中实现（现在正在维护）在线购物Web应用程序。 要求之一是，企业必须能够对客户添加到购物车中的商品应用规则，以自定义其体验和最终订单。很显然，必须建立业务规则引擎，并且为此我们实现了一个特定的“微服务”（如果仍然可以这样）。 在过去的一年中，此规则引擎变得越来越复杂，需要越来越多的数据（例如购物车的内容以及用户信息，他的角色，他的现有服务，一些账单信息等）才能计算这些规则。 目前，我们的shopping-cart微服务正在从其他微服务收集所有这些数据。即使部分资料已由所使用shopping-cart，大部分时间主要还是用来提供规则引擎。 新要求 现在，需要其他应用程序/微服务来重用规则引擎以实现类似的需求。因此，在当前情况下，他们将必须传输相同类型的数据，调用相同的微服务并构建（几乎）相同的资源才能调用规则引擎。 照原样继续，我们将面临几个问题： 每个人（称为规则引擎）都必须重新实现对数据的获取，即使他们自己不需要数据也是如此。 对规则引擎的请求很复杂； 继续朝这个方向发展，我们将不得不在整个网络上传输许多请求的数据（想想μsA调用μsB调用规则引擎，但是A已经有了规则引擎需要的一些数据）； shopping-cart 由于所有数据的获取而变得巨大； 我可能会忘记很多…… 我们怎样做才能避免这些麻烦？ 理想情况下，我们将避免为规则引擎增加更多的复杂性。我们还必须确保它不会成为瓶颈-例如，某些数据的获取速度相当慢（10 s甚至更多），因此我们实施了预提取，shopping-cart以便在调用规则之前数据更有可能存在引擎，并保持可接受的用户体验。 一些想法 让规则引擎获取所需的数据。这将增加它的复杂性，违反了单一责任原则（甚至更多……）； 在规则引擎获取数据之前实施代理μs； 实施规则引擎调用的“数据获取程序”μs，以一次获取其所需的所有数据（复合查询）。

12 design  architecture  enterprise-architecture  microservices  business-rules 

我想知道记录业务规则的正式和最常用的方法是什么？还有如何记录开发工件的UI规范（例如，记录表单字段以及按钮在表单，信息文本上的行为方式等）

12 documentation  business-rules 

我已经有一段时间了。我离那里最好的还很远。（当我独自坐在这个房间里时，我想知道自己是否是这里最好的。）但是，我开始了解自己的工具，并且我已经相信自己的推理和学习能力。 开始新工作时，我始终相信，只要我知道该语言，就可以学习该代码库。如果不是我所知道的语言或框架，我相信我可以掌握足以学习的概念（只需阅读文档）。这是我们作为程序员的技能技能的一部分，我为能够达到这一标准而感到自豪。 尽管如此，所有这些-我的主要弱点之一是为正在工作的客户快速学习和内部化业务规则-无论我是有薪雇员还是承包商。我对代码库很满意，但是特定业务的业务规则和流程似乎总是需要我一段时间才能完全理解。（例如，这可能是重写企业应用程序时的绊脚石。） 作为开发人员，快速有效地吸收业务规则和流程的最佳方法是什么？是否可能没有主题专家，或者仅仅具有与客户，公司或企业的多年经验？

11 business-rules 

用户故事的快速而肮脏的定义： "As a <role>, I want <goal/desire> so that <benefit>" 在这个公认的定义中，几乎没有空间定义业务规则，约束或用户输入。 一个简单的例子只是为了说明： "As a <librarian>, I want to <register new books> so that <students can find their availability online>" 在这个愚蠢的例子中，注册书时在哪里定义所需的字段？应该写在任何地方吗？还是应由产品负责人以口口相传通过所需的业务规则？

11 business-rules  user-story 

我想知道是否有人成功将Windows Workflow Foundation用于BusinessRules / Validation引擎，或者您是否知道一些示例代码或与此相关的文章。 如果您曾经使用过它，您怎么看？与其他BusinessRule / Validation系统相比如何？ 我在想类似的规则 if (A, B, and C) AllowAccess(); 要么 if (Value between X and Y) return true;

11 enterprise-architecture  validation  business-rules  workflow-foundation 

很多时候，我的业务对象往往会遇到信息需要经常跨越对象边界的情况。在进行OO时，我们希望信息位于一个对象中，并且处理该信息的所有代码应尽可能在该对象中。但是，业务规则没有遵循该原则，这给我带来了麻烦。 作为示例，假设我们有一个包含多个OrderItems的Order，该OrderItems引用一个具有价格的InventoryItem。我调用了Order.GetTotal（），它对OrderItem.GetPrice（）的结果求和，该结果乘以InventoryItem.GetPrice（）乘以数量。到目前为止，一切都很好。 但随后我们发现有些商品以一交易两卖。我们可以通过让OrderItem.GetPrice（）做类似InventoryItem.GetPrice（quantage）的事情并让InventoryItem处理来解决这个问题。 但是，然后我们发现二对一交易仅持续特定时间段。该时间段必须基于订单日期。现在我们将OrderItem.GetPrice（）更改为InventoryItem.GetPrice（quatity，order.GetDate（）） 但是然后我们需要根据客户在系统中待了多长时间来支持不同的价格：InventoryItem.GetPrice（数量，order.GetDate（），order.GetCustomer（）） 但是，事实证明，一对一交易不仅适用于购买多个相同库存物品，而且适用于InventoryCategory中任何物品的多个交易。在这一点上，我们举起手来，只给InventoryItem订购项，并使其通过访问器在对象引用图上移动，以获取其需求的信息：InventoryItem.GetPrice（this） TL; DR我希望对象之间的耦合度低，但是业务规则经常迫使我从各地访问信息以做出特定决策。 有好的技巧可以解决这个问题吗？其他人也会发现同样的问题吗？

10 design  object-oriented  business-rules 

我有兴趣看看其他人是如何做到的。尤其是在多个不同的客户端使用具有稍微不同的业务规则的相同软件库的情况下。您使用哪种实践来记录一切应该如何工作或业务规则。 基本上，这样一来，当团队中有新开发人员时，便可以轻松地查看事物的工作原理，因为使某些东西没有错误和使某些东西正常工作之间显然存在区别。 拥有资源而不是每次遇到有关如何处理某事的问题时都必须让架构师或BSA参与对话，这真是太好了。

9 documentation  business-rules