3

I'm aware of the general distinction between data and content, namely context, but here I have a case that is clearly causing a lot of confusion and debate within the company I work for.

There is a front-end team which manage an application which calls our data API. The confusion is that they want the content structured the way they are presenting it, because according them the structure implies domain knowledge (business logic) which they don't know anything about. The thing is, they came up with the structure in the first place... together with business. So is it business logic or GUI logic?

To illustrate, here's an example:

Our REST endpoint /car/123/repair/status returns:

{
   "status": "being_painted" /* actually an enumeration */
}

One customer journey scenario conjured up by the UX guy from the front-end team includes the concept of 'stages' in which the various repair statuses can be categorized into. This was discussed and agreed upon with our business product owner. The idea is that it provides a better visual overview to the end-user (not being business).

So instead of applying GUI logic to display 'stages' correlating to the 'repair status', they want us to provide it as data. Data that has no bearing on any IT process using a concept we don't officially know.

What they want:

{
   "currentStage": {
       "stage": "stage_recovery"
       "status": "being_painted"
    }
}

Is this business logic that should be part of the data API or is it GUI logic that should be part of the front-end application? Rephrased: should we provide such a granular API that it is completely specced for the highly specific presentational need or should we stick with just the statuses and create an API that only deals with data known to us internally?

One argument for providing statuses but not stages is the fact that statuses are based on the source data from our domain, while stages are based on the result of this (so not on source data). But I'm not sure how much of a real argument that is.

  • 2
    It seems quite weird to me that the GUI needs to express the data in stages if it is not a business requirements. It looks like you have a requirement discrepancy between the front-end team and the back-end team. I assume that you guys are both working on the same product in the end, which means you should sit together with the client to figure out the requirements. In my opinion, it hints toward a missing concept in the backend (the concept of stages). – Vincent Savard Jan 29 at 15:00
  • @VincentSavard While we have no IT process in the back-end that works with or relies on the concept of 'stages', our business owner and GUI team agree it makes sense to provide a user experience that includes stages for better overview. It's a purely visual optimisation. – Benny Bottema Jan 29 at 15:06
  • 1
    Personally, I've found that APIs with a single or few GUIs benefit greatly from a tight coupling. Rather than forcing the UI to do more work calling multiple endpoints and piecing things together, the API can provide a single endpoint with exactly what they need for that call. This simplifies the API too. Rather than having to code the world, you just need to fulfill one very specific use case. As an added benefit, the API doesn't leak internal class or database concepts. It just exposes use-cases. – bitsoflogic Jan 29 at 15:21
  • 1
    Well, we can't really answer this for you - you know the domain better then us. What is the purpose of your service? Who are the consumers of your API? What part of the business domain are you modeling - the backstage part or the customer facing side? If the latter, then "stage" might be a domain concept for you. Maybe you need to reexamine your domain and bounded contexts within more closely? Maybe you need to split the service, or provide consumer-specific facades? If you cannot answer these questions, find someone who can and discuss if any action should be taken with them. – Filip Milovanović Jan 29 at 17:08
  • The language you use to talk to customers IS NOT "not business logic". At some point a customer will ask about the stage of repair and you will not be able to respond by querying the database without looking at the GUI code - it seems to me that your assumption is wrong, not the GUI – slebetman Jan 30 at 2:39
7

Let me correct one thing in your question which looks like a wrong assumption to me - "business logic vs. GUI logic":

GUI logic and business logic are not mutual exclusive.

Even if there are no other backend processes which use the "stage" field, there seems to be a business process for which the "stage" field is required. This business process may be completely interactive and GUI triggered, nethertheless it is a valid business process.

In fact, the correct categorization of repair status values into stages is definitely domain logic (which is very obvious to me, since I have no knowledge of that domain, and I would have to ask a domain expert for getting to know the possible stages and the categorization).

This leads to the question how you want your responsibilities shared between front end and backend:

  • if you want the GUI as dumb as possible, and as much business logic as possible in the backend, provide the stage field from the latter

  • if you want the GUI to take responsibility for certain kinds of business logic, you can let it derive the stage field from the repair status there.

Both strategies can sometimes be justified, depending on the circumstances, so we cannot give a clear-cut recommendation for you. It is an architectural decision which involves on how your development process is organized, how your team works and how you want to maintain and evolve your system.

Note, however, the second approach bears a certain risk, because if you are ever going to extend the number of possible repair status values, you must make sure it is not forgotten to extend the mapping to stages as well. And if this mapping is coded into the front end, whilst the status fields are in the backend, the chances are way higher it will be forgotten.

4

The core of your business logic and the business services that you provide are based on the domain model. Ideally your domain model is a meaningful abstraction of business data and context. By itself it should be something that you could reason about with the business in terms of the domain model and have it make sense to all parties. Furthermore any business services would accompany this domain model to provide business functionality, actions and processes in a way that the business and technology can both mutually reason about.

From your comments, it sounds as if the business owner agrees that this concept of "Stages" makes intuitive sense to the business and is something that is not abstracted from their mind as a visual or technical detail. While "stages" may only be realized in the form of visual presentation to the user, it is apparently significant enough to the business to be realized as a domain entity of itself.

You should treat it as such. It should be considered a separate yet related business entity that may or may not have defined business/functional services that can act on it.

As an exercise to help you understand and better define your technical services, start with defining the business domain model and functional use case scenarios. From here you can define the meaningful business services that your business or product owner can reason about. From here you can then take this as input to define the technical services that are going to be built.

When designing the technical services (REST, SOAP, MQ, etc..) then you can start factoring in other matters like decoupling components and providing a clean separation of concerns such that you optimize future reusasbility of services.

  • "it sounds as if the business owner agrees that this concept of "Stages" makes intuitive sense to the business and is something that is not abstracted from their mind as a visual or technical detail." Can you elaborate on that a little bit? As far as I know for business it actually is just a visual detail: it makes sense to them to define stages for a better visual overview for the enduser. – Benny Bottema Jan 29 at 15:30
  • I've amended the question with the sentence "The idea is that it provides a better visual overview to the end-user (not being business)". Does this change the relevancy of your answer? – Benny Bottema Jan 29 at 15:45
  • 1
    @BennyBottema No I don't believe so. I think we can both agree regardless of how you classify it, that it is still a requirement. A requirement can stem from any number of stakeholders. If the UX designer justifies the importance of a ribbon bar then it is a UX requirement. If the architect justifies a performance requirement of < 2s to avoid some technical constraint then it is an Architecture requirement. If the business justifies the same performance requirement because of negative impact to the user then it is now also a business requirement. – maple_shaft Jan 29 at 16:55
  • 1
    (... cont) The business requirement is something that the business can reason about and desire in the function and form of the software. Requirement classifications are not mutually exclusive, thus it stands to reason that business logic and presentation logic are not mutually exclusive either. – maple_shaft Jan 29 at 16:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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