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