我们有一个网站，可以在其中输入交易并通过工作流程。对于分层应用程序，我们将遵循标准 BLL（业务逻辑层）、DTO（数据传输对象）、DAL（数据访问层）等。我们需要将所有内容分开，因为某些事务将跨越具有不同业务逻辑的多个应用程序。
我们还有一个后端处理器。一旦工作流程完成，它就会处理我们的交易。它适用于各种第三方系统，其中一些不稳定，或者与它们的接口不稳定，然后报告交易状态。每个网站都有自己的后端处理器版本。
现在的问题是，对于 N 层，他们为每个应用程序建议一个新的 BLL。从上面的应用程序布局来看，后端处理器和网站可以说是一个应用程序一致行动，或者是两个具有不同业务逻辑的应用程序。处理这个问题的理想方法是什么？它像一个系统还是两个系统？
如果您将关注点分开，那么我认为您将能够将它们视为具有单个业务逻辑层的同一个应用程序，两次编写相同的代码是没有意义的。诀窍将强制分离网站的用户界面部分和 BLL 库中的业务逻辑之间的关注点。
性能也将成为一个问题，您必须确保您的批处理不会阻止您的网站执行由于您的资源而需要执行的任务。这可能是让它们更加独立的一个论点，但是因为它们可能无论如何都共享一个数据库（或其他一些基于文件的资源），那么无论如何这可能是一个问题。
我会保留一个为接口编程的通用业务逻辑库，并与您的其他问题完全分开。
您可能会考虑对功能进行分区以反映利益相关者的组织。通常，如果您有两个不同的组织组，那么如果功能被类似地划分，那么开发和管理需求就更容易管理。反之亦然。
我们中的大多数人不会花太多时间来编写探索硬件和软件功能外部边界的应用程序。
我在过去几年学习 MVC 时学到的一件事是我所说的应用程序逻辑和域逻辑之间的区别。我不再喜欢业务逻辑这个术语，因为它有太多的包袱来自所有相互冲突的理论和实践，这些理论和实践过于松散地使用了这个术语。
领域逻辑是“传统”业务逻辑，事情应该如何行动，他们需要什么（验证）等。应用程序逻辑是特定于您的领域的给定表示的任何内容，即当用户单击此提交按钮时的 IE您的网络应用程序，然后他们将被定向到此处的此网页（请注意，这与 WinForms 应用程序或后台处理器的工作方式无关）。应用程序逻辑应该存在于您的应用程序中。域逻辑应该存在于您的 BLL 和更低版本中，并且可以在可能使用您的通用“业务逻辑”的不同应用程序中重用。
有点笼统的答案，但我希望这会有所帮助。
执行此操作的“理想”方式取决于手头的项目和系统的各种要求。
我的默认设计是让它充当一个应用程序。但是，如果有更多重量级进程正在发生，我喜欢创建一个批处理进程，其中请求作业的参数被存储并由一个单独的进程执行。