Where to put intermediary business logic in a backend

Question

Consider you have a GravityLogic and a WeakForceLogic class. In themselves both provides tons of business logic. Now you want to create interactions between those which produce a complete different set of result. Would you rather create GravityWeakForceInteractionLogic class if this is going to generate a lot of new algorithms or put the new logic elsewhere (for example Helper classes) ?

I'm struggling a lot in organizing such intermediary business logic code on the backend side. The gravity and weak force logic are just examples. What I'm trying to avoid is having "linking" business logic between backend objects in the upper layers. I also want to provide a more robust API for our frontend. I just find myself always wondering where to put these algorithms.

This question is for any object oriented language. I know that each case could call for its own place but for now, let's assume that this linking logic is complicated and would bloat the original classes it is trying to connect in some way and extract meaningful information.

Answer 1

Since our problem domain seems to be physics, I'm going to make a few assumptions in my answer:

1. GravityLogic contains methods that encapsulate mathematical algorithms for solving gravity problems

2. WeakForceLogic is a class with algorithms for Weak Force from particle physics.

Understanding the problem domain is the key here.

If logic requires gravity and weak force, where does it go?

How does gravity and weak force relate to each other in physics? That's the question to answer. So, the places to put this coordination logic would be:

• The interaction between the two may have a term or idea in physics, which becomes a new class that performs these coordinating calculations.

• Expose more methods on GravityLogic or WeakForceLogic that takes the other class as an argument.

• A "use case" class that handles instances of these two classes to perform larger calculations.