Hello community!

I'm ambivalent regarding what type of business logic should be performed in CS vs BL modules. I tend to only put entities, CRUD actions and validations on user input in the CS module, while in the BL modules, I put more advanced business logic (calculations etc), as well as orchestrating calls to several server actions in the CS module.

Now, regarding for instance the Single Responsibility principle and the likes, I find this a good approach. However, I find that when I write Unit Tests for my CS module's actions, I'm not completely covering the code. Say, for instance, that I have an action in my BL module that first calls an action in the CS module to change an report's status to approved, and then another action in the same CS module that removes some metadata that should not be present in approved reports.

If the action calls were made to different CS-modules, this would be a no-brainer; but in this case, with the actions being in the same CS module, would it be considered overkill to extract the business logic to the BL module? If it was all grouped together in one action in the CS module, I would be able to test it through a unit test; however, I'm not sure I would consider such an action a "unit" in the actual sense of the word, and I would violate the Single Responsibility principle.

Then again, I would like to cover the expected business behaviour in my tests...

Any input on how to approach this? Should BL modules only contain orchestration calls to different core modules, or should they be viewed as an isolated repository for all business logic to increase code isolation and readability? Should BDD Framework unit tests cover business logic?