How do I create a simple yet complex business layer?

Question

I'm working with a fairly complex web application. It's split up into the following layers:

• Presentation - HTML
• Service layer - A REST and SOAP API communicating with the business layer
• Business layer - Contains the business logic.
• Data access - Provides access to the storage (SQL etc)

The business layers contains classes encapsulating specific areas, such as customer registration, user management and more. The problem we are seeing is that the business layer is starting to get a bit messy. We have a single class handling customer management but as this area of the application grows more and more complex, the class grows and grows and become messy.

For example, we may have the following classes

• class CustomerManager

  • void CreateCustomer(...)
  • void DeleteCustomer(...)

• class UserManager

  • void CreateUser(..)
  • void DeleteUser(...)
  • void ActivateUser(...)
  • void InactivateUser(...)
  • void ResetPassword(...)

Creating a customer involves creating users as well. So CustomerManager calls misc methods in the UserManager class. As the application has evolved, creating a new customer means roughly 10 different things needs to be done except for registring the customer in the database, such as informing sales, audit logging, configuring default user accounts, creating a default configuration for the customer, notifying end-users of their auto-generated passwords and more. So CustomerManager.CreateCustomer grows to ~100 lines of fairly hairy code.

I'm trying to think of a good way to handle this but am assuming that there's some common good way to do this which I'm simply not aware of.

I've considered creating "Task"/"Command" classes implementing small sub-processes and then let the CustomerCreation.CreateCustomer simply execute a set of tasks. I would have more classes but they would each do less things.

I've also considering implementing some kind of global application-level event/plug-in systems where CustomerManager.CreateCustomer just creates the customer in the database and then publishes an event that the customer is created. Plug-ins/something can then subscribe to these events and do stuff such as informing sales and logging the fact. Using this method, I wouldn't have to actually update CustomerManager.CreateCustomer when I want to do more stuff which is something which feels attractive to me.

What obvious design pattern am I missing?

Answer 1

As @DocBrown said, plugins are mostly useful when you want to allow third parties to be able to extend your application. But that doesn't mean you can't use similar techniques in your design as what gets commonly used when interfacing with plugins.

For example, if a lot of the code you have is along the lines of "after creating the customer in the databse, components X, Y and Z need to be informed so they can take their appropriate actions", then you can use the Observer pattern there to decouple CustomerRegistration from X, Y and Z (and at a later time, A and B could get added to that list as well).

On the other hand, if your logic has a lot of ifs, buts and unless tests in it, then there is no real way to reduce the complexity of the code, because it is inherent in the business rules that the code represents.

Answer 2

Plugins are nice if you want to let third-parties extend your current application, but if that is not the case, you risk to make the architecture more complex than necessary.

Do yourself a favor and before trying to throw randomly some patterns at your business layer, start with small and simple things first:

• if you have a method with 100 lines of code, start refactoring to many smaller methods.
• make sure your smaller methods have all a single responsibility (see also: SOLID), and try to achieve a state where the parts of the calling methods work all on the same level of abstraction
• when you have enough small methods dealing around a specific topic, you may extract them to classes (especially when the smaller methods exclusively share some data)
• you can have the "command" pattern in mind for the new classes you create. If it is really a good idea to use that pattern will reveal after you have created some of that helper classes and they look all like similar commands, with a command-like interface

Answer 3

Component architecture can provide good tools for fighting complexity of the business layer. For example, notifications can be done with registering subscribers (event handlers). A lot of logic can be done by adaptors, which will provide certain specific interfaces to your User and Customer interfaces. This way logic can be decoupled, making large monolithic classes unnecessary. Hopefully your platform already has some proven component architecture you can use, which is much better than implementing "plugins" from scratch.

Older answer (see first comment):

My first impression of having CustomerRegistration and UserRegistration classes with the methods mentioned is that OO analysis has not been properly accomplished. I always thought that having sensible entities at business layer is the only way to prevent the mess. My advice would be to redesign (if it is not late yet) the business layer classes to better reflect business entities and not frontend processes. It may well be, that after such a redesign complexity will be a fraction of what you have now, and, more important, natural representation of the problem domain will answer your goals better than classes, combined with seemingly related functions.

For example, even as such, UserRegistration should not have DeleteUser method! The task naturally belong to UsersManager class or maybe UserRegistry, if you wish.

In short, I think the problem is that classes are formed around action-like entities, which requires much more interconnections (=mess) than class system around (say) User, Customer, and Managers of those two (managers are more like containers).

There is little point of making User Management OOA from scratch. Good examples can be found from many frameworks, and sometimes they handle much more complex things, like fine-grained authorization, role/permission management, group management, etc.