If we look at the typical software architecture guide, it will have the domain layer, application services, and UI, where domain layer contains the business logic.

This is a nice clean separation until we run into a case where putting "business" logic on the client-side makes a lot of practical sense.

For example, let's consider a typical React/Redux app over REST API, which pulls a list of items from an API, categorizes them using some criteria, and displays the results. The point here is that the categorization a) can be performed using already loaded (into Redux store) data set b) changes depending on the user selecting a subset of data.

On one hand, it seems that since we already have all the required data on the client, we can perform calculations (which could be entirely trivial or fairly complex, but let's assume we're not worried about exposing any business secrets here) on the client-side and avoid trips to the back end every time the user changes the selection.

On the other hand, this means that the business logic is now spread across multiple layers, the app design is less obvious, and the app is potentially somewhat harder to debug/reason about.

So I'm curious what do others think about having a business logic on the client-side vs strictly in domain layer and how do you determine which logic (if any) can go to the client-side vs "must stay on back end"?

1 Answer 1



Rub your eyes and look at what you are discussing: a WebApp and a Server that communicate across a network.

That is literally two separate applications with a network interface.

In fact you have just reinvented the Thick client. Just instead of installing it on Windows, and compiling it from C++ you are writing it in JavaScript and installing it in a browser tab.

What this means is that each application (the thick client, and the api server) both have need of a business logic layer.

Now if your server is written in javascript. You might be able to share some of that business logic. But you probably don't want to. The business concerns of the backend are different to those of the front end, so aside from the data objects for communications, or some of the more general utilities their probably isn't much worth sharing. Sharing introduces its own headaches, as both applications will want to head in their own directions.

Domain Logic

There is a balance between what can be done by the client and what can be done by the server.

  • When its all in the server, the client is called a thin-client.
  • When its all in the client, the client is just called an application, with maybe some networked services available
  • When its balanced, the client is called a thick client.

If you are going for a thin client, the absolute minimum required information for presentation is given to the client a video stream would be ideal, and the raw inputs are passed back to the server.

If you are going for a complete local experience, then everything goes in the client. Only those things which cannot be done locally be that for secrecy, or some form shared service are kept in the server. Even better if the server isn't even responsible for distributing the client.

If you are going for a thick client, its a matter of taste and circumstance.

  • At the very least the client needs the logic for handling the UI. Which includes responding to input, formatting, and layout.
  • At the very least the server has to have the Secret/compute intensive/server storage features.
  • Every other feature has to be traded off on whether it makes more sense in the client, or in the server.

A good way to figure this out is to pick a range of client devices. How much ram, cpu, etc resource they have available. Everything from the smallest device you will support up to the beefiest device you expect a client to have.

  • Everything that can be put on a client, and fits in the smallest device belongs in the client.
  • Everything that can be put in a client, and can be handled by the powerful device easily, and by the least powerful device but just takes longer, has a compelling argument for being in the client.
  • Everything that can be put in the client, and can only be handled by the more powerful devices has an argument for going into a pro version, or staying on the server (maybe both).
  • Everything else, even if it can go in the client is obviously to taxing/secret/impossible for the clients device. It has to stay in the server.
  • So in my situation (enterprise apps, few users, and desktop browser support only), it distills to "for a thick client, its a matter of taste". Which, I guess, it is.
    – user227895
    Jul 20, 2020 at 22:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.