Hi, I’m wondering how you handle business logic in client javascript code. In examples on GitHub - Particular/Workshop: SOA Done Right (checked all branches) there is no javascript business code example on reaction to user actions. According to ‘ui composition and branding service’ chapter from ‘intro to soa’ part in Udi’s adsd course services shouldn’t be responsible for rendering and positioning widgets on screen - it’s branding service which is responsible for. However responding to user clicks, mouse moves, etc often causes business actions and we want handling these actions on the client in javascript - for example when offline and not going to the server back and forth every time. Because branding service doesn’t know how to handle business actions we have to pass that action to service which is interested in that specific action. However it can become very messy very fast, because there is a lot going on on the client - handling plenty of browser events, browser apis, mapping everyone of them to for example redux event and then translating response back to ui action, which increases in fact coupling between business services and branding.
My proposition is to give services responsibilities for rendering their part of ui, so they can handle ui actions right away and don’t have to translate them. I’ve created application illustrating that solution which is available on GitHub - padzikm/CompositeUI.js: CompositeUI in SOA Done Right architecture style . In my solution branding provides common set of webcontrols, which are styled accordingly to enterprise’s brand. Services often use these styled webcontrols to provide widgets and encapsulate business logic to the client app. Also it enables services to be independently deployed from each other in the ui too - everything is hooked up during app startup. However it is opposed to what Udi said in the adsd course that services aren’t involved in rendering, so I wonder what do think about my solution and maybe you have answer to do it without involving services in rendering part.
Hi Michal,
TL;DR : The javascript you’re talking about is part of a service.
It’s been a while since I’ve attended ADSD, but from what I remember, Udi definitely doesn’t intent to say that everything in the UI belongs to branding. Branding does what its name implies, do everything related to branding. Because the look and feel, styling, etc. is overarching multiple services and that’s why there’s a branding service that does nothing else.
However the javascript that is related to business logic, most certainly belongs to a specific service. A service is the technical authority for everything from database (data storage) to the user interface. So that includes HTML and JavaScript.
Then there’s also IT/OPS, which is not responsible for business logic but rather infrastructural related code, to put it in my own simple words. So libraries for logging, authentication, but also other stuff go in there and are decided by the team that runs IT/OPS, usually the architects and people that decide what features will be build and what goes in which service. They also make sure composition of the screen and the viewmodel is possible.
Yes, of course - business logic is handled by appropriate services, but there is a lot of translation between user actions - clicks, web apis, browser events, etc - to some kind of event that service can handle. For example dispatching redux event for every mouse click. But as I said there are lots of events on the client, plenty of mouse moves, keystrokes, etc that triggers business actions (form validation, gathering data, dynamic forms, dynamic interaction with user in response to his/her actions). As a result branding have to for example dispatch every event (with meaningful event name, which for every mouse click on different part of the screen can be very hard to manage) so that event can be subscribed to by service interested in handling user action. Next there have to be translation between service’s result to screen action - for example triggering popup, highlighting some widgets, etc (that response event also has to have some meaningful name that branding can understand what exactly to do, so that in practise increases coupling between branding and services). So my thinking is to put closely service data and service behaviour, as in non-ui parts of services. In order to let service freely operate on its data and not couple it to branding service as part of ui events translations it has to have easy access to it, so we have to allow ui part of service to render its data and operate on it. That’s why in my solution services render widgets together with behaviour operating on these widgets and branding produces ready to use, enterprise styled web controls that services can use. As a result branding, it/ops and services are still logically and physically decoupled and can be developed separately - for example handling bitcoin in addition to standard currencies requires change in only one service top to bottom and other services and also branding don’t know about that. But as I said that requires services to take some responsibility for rendering part and I wonder how to rich ui web client without services being involved in rendering.