> ticket comes, new feature is requested
> create the new feature from scratch. Code is neatly splitted in files and methods, each with clear responsibilities
> every method is documented, there are clear service layers for the business logic, which resulted in controller having 10 lines of code, give or take
> commit the whole code, everything works
> check the develop branch today, team leader littered business logic in the controllers because "the codebase is a mess anyway"

Controller is the place for business logic. Assuming it is route/controller/service api architecture.

Just saying. If the business logic is in the service it is in the wrong place.

@irene no.

Like, definitely fucking not.

Literally what the fuck is this.

@IHateForALiving Is this Express?

Yeah... I'm so confused now. You usually always do Business logic in the controller, and database logic in a Repo. You obviously wouldn't do it in the factory... So idk where next you would put the logic. Help me out here.

I guess define things. I most often make multi-tiered REST services. That is presentation/logic/data layers.

Presentation layer is the interactions that someone's client does at a route. Middleware builds a meaningful request context. The client can't interact with the data directly, and probably never knows what that data looks like or where it lives; they just build against the api version. Controller handles parse, validate, determines the action, initiates an action, and converts the response into something useful. Validate may need info from service layer. Service layer performs the action to get/set data from external apis, DBs, serverless functions, or etc.

That way the client can do simple actions without knowing or caring about how the work is done. You can make changes as much as you need and the client never needs to change until you release a new api version.

If you just need a route to set or get directly use GraphQL. Since I build multitenant apps, and organizations have parent or child orgs, there is usually a bunch of info for the user in a JWT on the request. You then need to be sure that data access is scoped to their org, or child orgs, and that ends up being validation business logic in the controller because you probably won't provision thousands of users for a DB or whatever.

@iSwimInTheC It largely depends on what you see as a controller.
Lets assume conventional model-view-controller.
In my general interpretation, model is where I would suspect the core logic to reside. The controller receives user input, be it via a text field in the context of a ui or as some json payload for a REST API and converts it to a structure/command that is forwarded to model which applies it.

Do be honest the most important thing in architecture generally is to draw clear boundaries between logic that is integral to the application and any external technologies used (storage (databases, disk, ...), transport (REST, gRPC, ...), ui technology (QT, GTK, ...), etc.). This way you can exchange the technologies used without having to rewrite the entire application.

There is some confusion here.

LAYER 1, controller: takes HTTP requests and forwards them to LAYER2

LAYER2: contains business logic and read data from\writes result to a db using a LAYER3

LAYER3 repository

You could call the business logic from jobs, from console, from RPC calls and whatever you want; the controller is just whatever takes care of reading HTTP requests and translate them into something you feed to a service. Which in turn uses the repository for long term storage; results might be sent to a db, to a file, to an entirely different API altogether and you wouldn't care.

@IHateForALiving
your layer 1 would be routing layer in my world
Your layer 2 would be controller layer in my world
Your layer 3 would be service layer

The routing is another thing altogether. Takes a request at /api/bufo/bafo and call the controller, which in turn performs all the circus I've highlighted earlier. Basically the bread and butter of Spring applications.

What exactly is business logic? I’ve seen several different definitions of what it is ranging from the number crunching at the model layer to the more client facing stuff like login workflows (login failed? User sees messsge like “invalid password”).

My team’s arch uses controllers as dumb receivers of http requests which extract url params or query strings from the requests, calls whatever services are needed, and packs up the output as JSON back to the client. Not saying it’s the “one way” but it’s how we roll the dice

@TeachMeCode it's also how we decided to develop the feature I'm talking about. Which held true until someone started littering code around.

People generally get promoted to one or two positions above what they are actually component for