How to structure business layer logic (app with much complicated business layer logic, calculations etc.)

Question

We are developing a.NET web application that uses WebApi. We have separate layers:

• UI (HTML, CSS, js etc.)
• ApiController - receives input DTOs from the UI and calls the appropriate endpoint in the Business Layer (for instance, StudentBLL.Add or StudentReportBLL.GetFollowReport)
• Business Layer - contains all business logic; doesn't save data into the DB directly, but calls the DAL (data access layer).
• Data Access Layer (uses Entity Framework for CRUD or, in more complicated scenarios, performs some complicated queries and so on -- it does not have business logic).

Additionally:

1. We use "Business Objects" (classes that EF operates with; these objects usually are transformed into database tables in our relational database).
2. We use "View models" (used in Controllers and also in Business Logic).
3. We use Automapper to map Business Objects to View models. Mapping usually is done in our Business Layer.
4. We also have dependency injection (all BLL and DLL classes have interfaces).
5. We have additional Services like ExcelReader, OurEmailSender, Workflow etc. We do not have problems with these.

So, so far we have tried to separate all logical parts.

Here is definition of architectural problem I am faced with: It is written much about overall architecture issues and how to separate layers. But the problem which I face with is that we have a lot of logic in our Business Layer. When we just started to develop this application, the code resulted in very large Business Layer classes with many private methods. Then we started to create Helpers. This helped us to clean our BusinessLayer a bit, but still, we have very large Helpers and something like "HelpersOfHelpersOfHelpers". Of course, we often name it differently, like "Importer" or "Calculations" or "Exporter", but still, often these are just Helpers with some weird names.

Can you give some clues how to structure Business Logic? These could be pattern names, some suggestions on additional reading or anything else.

Answer 1

You are asking the fundamental question of architecture: "I have a lot of logic...how do I structure it?" It is hard to answer such a general question in brief since numerous books have written about various aspects of this problem.

But in short, you probably suffer from "God objects", and names like "XxxHelper" indicates classes does not have a clearly defined purpose. It is much easier to think of a meaningful name if the class have a delimited and well-defined purpose.

You have to start by separating the code into modules and classes with clearly defined purposes. An approach would be to draw sketches or mind-maps of all the tasks and operations in the business logic and try to group them into layers, subsystems, core, services etc. It seems you already have this principle down for the overall architecture, so you need to apply the same design process to the business logic.

The fundamental design principles: Layering, slicing, separation of concerns, single-responsibility, high-cohesion-low-coupling and so on should be applied at all levels of the architecture, not just the top level.

If you want a more formalized approach, you can look into Domain Driven Design, which describes a number of approaches and patterns for structuring business logic (or domain logic, as it is also called, which is basically the same thing).

Answer 2

A lot of logic in you business layer is a good problem, it's supposed to be there. Similarly private methods aren't necessarily a huge problem so long as proper object oriented design is followed. The next step would be to utilize object oriented principles and design patterns to abstract and isolate logic into closed units. Factory or builder patterns may be helpful with importing, and a possible way to isolate complex calculations is to use the strategy pattern. The important things to worry about are having lots of static methods or classes with many public methods that are unrelated to each other or almost identical methods.