我可以使用应用程序服务和业务对象模式来简化和更好地执行biz过程吗？

Question

我们已经为一个金融应用程序设计了一个3层网络应用程序。

业务层被进一步划分为管理层、助手层、利用层来模块化代码，并将不同的功能(即核心业务和非业务代码)相互隔离。

Util层具有非业务功能，这些功能是在特定过程(如DateUtils.java、EncryptionUtil.java等)中所需的。

帮助层具有特定于特定业务流程的业务逻辑，而在其他业务流程(如SomeThirdPartyInterestCalculationHelper.java、SpecificRequestBuilder.java )中不需要业务逻辑。

管理层有控制流程的业务流程，并实现业务逻辑的某些部分，例如，CustomerAccountManager.java对于客户帐户的CRUD操作有不同的方法。它调用不同的助手、实用程序、DTO等并完成工作。它还实现了一些业务逻辑。因此，它执行BPM角色的混合以及核心业务流程逻辑的部分。

随着过程变得复杂和长，我的管理层正在增长，看起来不像组织良好的代码。

我希望将执行特定角色的层分开，即业务流程控制器、业务流程执行(核心业务逻辑)、CRUD操作(这是特定于DB的、帮助程序(特定于流程)、非业务逻辑)。

有什么更好的设计模式可以实现这一点呢？

我正在尝试业务对象模式，以隔离业务逻辑的不同部分，并将其与应用程序服务模式耦合。

因此，对于执行业务流程，我需要：

1. ApplicationService -将是一个纯业务流程控制器，它调用不同的业务对象，并根据BO方法的结果控制执行。
2. BusinessObject1 -不同方法的核心业务逻辑-由ApplicationService调用
3. BusinessObject2 --不同方法中的核心业务逻辑--由ApplicationService调用(如果BusinessObject1变得更大或者BusinessObject 1和2可以执行特定的业务功能)
4. IntegrationBusinessObject -调用业务流程中所需的其他第三方服务
5. 对于特定域实体的DomainEntityBusinessObject - CRUD操作在CRUD操作之前或之后也需要一些业务级别检查。
6. 适配器-转换第三方服务的格式-可由IntegrationBusinessObject调用

其思想是使类更加紧凑，并执行特定的业务功能。另外，从单个类(Application )控制进程，这样更改流程就更容易了。

这种设计可维护性和可伸缩性吗？

Answer 1

设计是好的，但要确保避免压倒经理与无关的任务。

经理只应执行编制任务，否则，必须创建关心特定行为和非编制任务的新类。大多数情况下，这将在您的助手层。

这样，您就拥有了可维护的层。

此外，也请不要按大小，只根据相关性分开班级。因此，每当您看到任务与该类没有直接关联时，请创建一个新类并在原始类中使用它。这使得类更易于维护和理解。