Can I use Application Service and Business Objects patterns to simplify and better execute biz processes?

Question

We have designed a 3-tier web app for a finance application.

The business tier is divided further into layers like manager, helper, util layers to modularize code and isolate the different functions i.e. core business vs non-business code from each other

Util layer has non-business functions which are required during a particular process e.g. DateUtils.java, EncryptionUtil.java etc

Helper layer has business logic which is specific to particular business process and not required in other business processes e.g. SomeThirdPartyInterestCalculationHelper.java, SpecificRequestBuilder.java

Manager layer has business process which controls the flow as well as implements some parts of business logic e.g. CustomerAccountManager.java has different methods for CRUD operations for customer account. It calls different helpers, utils, DTOs etc and gets the work done. It also implements some pieces of business logic. So,it performs mix of BPM role as well as parts of core business process logic.

As the processes become complex and lengthier, my manager layer is growing and does not look like well organized code.

I want seperate layers doing specific roles i.e. business process controller, business process execution (core business logic), CRUD operations which are DB specific, helpers (specific to processes), non-business logic

What can be a better design pattern to achieve this?

I am trying out Business Objects patterns to isolate different parts of business logic and coupling it with Application Service pattern.

So, for executing a business process, I would have:

1. ApplicationService - Would be a pure business process controller calling different business objects and controlling execution based on results of BO methods
2. BusinessObject1 - Core business logic in different methods - Called by ApplicationService
3. BusinessObject2 - Core business logic in different methods - Called by ApplicationService (if BusinessObject1 grows bigger or BusinessObject 1 and 2 can perform specific business functions)
4. IntegrationBusinessObject - To call other third party services required in business process
5. DomainEntityBusinessObject - CRUD operation for a particular domain entity required in process...will also have some business level checks required before or after CRUD operations
6. Adaptors - To convert formats for third party services - May be called by IntegrationBusinessObject

Idea is to make classes more compact and doing specific business functions. Also, control the process from a single class (Application Service) so that changing the process can be easier.

Is this design maintainable and scalable?

Answer 1

The design is good but make sure to avoid overwhelming the manager with non-relevant tasks.

Manager should only do orchestration tasks, otherwise, new classes have to be created that care about specific behaviors and non-orchestration tasks. Mostly this will be in your helper layer.

This way you are having maintainable layer.

Also please don't separate classes by size, only by relevance. so whenever you see the task is not directly relevant to this class, create a new class and use it in your original class. this keep the classes more maintainable and understandable.