具有网站和后端事务处理器的N层设计

Question

我们有一个网站，在那里交易被输入并通过一个工作流程。对于分层应用，我们将遵循标准的BLL(业务逻辑层)、DTO(数据传输对象)、DAL(数据访问层)等。我们需要将所有东西分开，因为一些事务将跨越具有不同业务逻辑的多个应用程序。

我们还有一个后端处理器。一旦工作流程完成，它就会处理我们的事务。它与各种第三方系统一起工作，其中一些系统不稳定，或者与它们的接口不稳定，然后报告交易的状态。每个网站都会有自己版本的后端处理器。

现在的问题是，对于N-Tier，他们为每个应用程序提出了一个新的BLL。通过上面应用程序的布局，可以认为后端处理器和网站是一个统一操作的应用程序，或者是具有不同业务逻辑的两个应用程序。处理这个问题的理想方法是什么？让它表现得像一个系统，还是两个系统？

Answer 1

我在过去几年学习MVC时注意到的一件事是我所说的应用程序逻辑和域逻辑之间的区别。我不再喜欢业务逻辑这个术语，因为它背负了太多来自所有相互冲突的理论和实践的负担，这些理论和实践过于松散地使用了这个术语。

域逻辑是“传统的”业务逻辑，事物应该如何运行，它们需要什么(验证)等。应用程序逻辑是任何特定于您的域的给定呈现的东西，IE当用户在您的web应用程序中单击此提交按钮时，他们将被定向到此处的网页(请注意，这与WinForms应用程序或后台处理器如何工作无关)。应用程序逻辑应该存在于您的应用程序中。域逻辑应该存在于BLL或更低版本中，并且可以在可能使用公共“业务逻辑”的不同应用程序中重用。

这是一个通用的答案，但我希望这能有所帮助。

Answer 2

如果您很好地分离了您的关注点，那么我认为您将能够将它们视为具有单个业务逻辑层的相同应用程序，没有必要两次编写相同的代码。技巧是在网站的用户界面部分和BLL库中的业务逻辑之间强制分离关注点。

性能也将是一个问题，你必须确保你的批处理不会因为你的资源而阻止你的网站执行它需要执行的任务。这可能是一个让它们更独立的论点，然而，因为它们可能无论如何都共享一个数据库(或其他基于文件的资源)，所以这可能是一个问题。

我会保留一个通用的业务逻辑库，用于接口编程，并与您的其他关注点完全分离。

Answer 3

您可以考虑对功能进行分区，以反映利益相关者的组织。通常，如果您有两个不同的组织组，那么如果功能被类似地划分，那么开发和管理需求将更容易管理。反之亦然。

我们中的大多数人不会花那么多时间编写探索硬件和软件功能外部边界的应用程序。