design-patternsapi-designweb-development-serverbusiness-logic

Is a business logic layer necessary if I take logic out of the controllers?


I'm working on an API project where some of the endpoints have a lot of business logic in the controller's action methods. A lot of literature suggests that I pull out this business logic into a completely different project and have the API project reference it. My question is do I really need a separate domain/business logic layer? It seems like I could extract the business logic into its own classes within the API layer and that would accomplish the same thing. I appreciate the insight!


Solution

  • Having a separate project for the domain/business layer has some advantages.

    1. Other layers can also use the domain/business classes you create without having to know about/reference the API layer and its dependencies.

    Imagine Your API layer uses AbcCalculator (which you've defined in your API layer). If you want to use AbcCalculator in your Data Access Layer then you'd have to reference your API layer. Then you can't reference your Data Access Layer from your API layer because it's a circular dependency.

    1. When you write tests for your domain/business layer then your test projects won't need to reference the API projects and their dependencies.

    2. A separate project means developers won't accidentally reference objects that genuinely belong in the API layer, in the domain/business layer. This leads to difficulty in separating the layers later on because you end up with circular dependencies.