Timeline for Is this data as a result of business logic or is this content as a result of GUI logic?
Current License: CC BY-SA 4.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 30, 2019 at 18:00 | history | tweeted | twitter.com/StackSoftEng/status/1090671173908811776 | ||
| Jan 30, 2019 at 5:33 | comment | added | Benny Bottema | @slebetman it's not language business has used with customers, but you're right, now that it has been made part of the visual user experience, it probably is. | |
| Jan 30, 2019 at 2:39 | comment | added | slebetman | 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 | |
| Jan 29, 2019 at 17:08 | comment | added | Filip Milovanović | 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. | |
| Jan 29, 2019 at 16:39 | answer | added | Doc Brown | timeline score: 7 | |
| Jan 29, 2019 at 16:12 | history | edited | Benny Bottema | CC BY-SA 4.0 |
added 2 characters in body
|
| Jan 29, 2019 at 15:43 | history | edited | Benny Bottema | CC BY-SA 4.0 |
added 94 characters in body
|
| Jan 29, 2019 at 15:21 | answer | added | maple_shaft♦ | timeline score: 4 | |
| Jan 29, 2019 at 15:21 | comment | added | bitsoflogic | 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. | |
| Jan 29, 2019 at 15:06 | comment | added | Benny Bottema | @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. | |
| Jan 29, 2019 at 15:00 | comment | added | Vincent Savard | 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). | |
| Jan 29, 2019 at 14:50 | history | edited | Benny Bottema | CC BY-SA 4.0 |
added 250 characters in body
|
| Jan 29, 2019 at 14:44 | history | asked | Benny Bottema | CC BY-SA 4.0 |