Chapter 6 - Extracting the Business Logic
As I promised earlier, we're getting deeper into the world of semantics.
First, let's try to identify how many layers we have in an average application. Usually what we see is the UI, then everyone knows, we have a backend and finally, we need to store our data somewhere.
Every developer knows from the first day if you repeat something that's a sign of bad design. Usually called "code smell". I have already touched the surface of a problem I have faced since I started developing. And it is the hidden layer of the business itself.
If you look at your code I bet you can tell from every line in there if it's there because of the language/framework, or because of the business-related requirements. Let's get back to our initial example project and take for example an input-field from our form:
<mat-form-field> <mat-label>Summary</mat-label> <input matInput placeholder="Summary of task" formControlName="summary"> <mat-error *ngIf="summaryControl.hasError('required')"> Summary is <strong>required</strong> </mat-error> </mat-form-field>
The whole block is there because of the business requirements of a summary property on the Task entity. But the details of the input, the tags, attributes, the composition of the source code is there because of the framework we chose.
Can we spot where this form reappears again? This part is not as obvious. Let me show you, then I'll explain the reason behind:
[FunctionName("BlogTaskCreate")] public async Task<IActionResult> Create( [HttpTrigger(AuthorizationLevel.Anonymous, "post", Route = "tasks")] HttpRequestMessage req, ILogger log)
Yes indeed, this is our function. When we talk about forms, we usually think only about the UI representation and generously forget about the basics of REST concepts. I look at a POST/PUT/PATCH operation over a REST API endpoint as a headless form. It simplifies a lot for us if we do so.
First, we read the data from an external source in both cases. On the UI side, the user is the source of data, while on the API side it's the request. Then we work with similar model representation on both ends, but not the same code, as we use different languages. Also, we have a validation code on either side.
In a regular development process, you prepare the requirements and then hand it out to both the UI and the backend teams. They both create their own interpretation of your expectations, and when you integrate them you will see the differences in understanding.
Wouldn't it be nice if the UI would handle only the task of creating components that can be reused by anyone, and the backend would be responsible for creating the libraries that can handle any form, list, the flow we talked about so far? And we could just leave the business logic to the person having the only clear understanding of the requirements, eg. the business analyst?
No, I'm not dreaming. In the following posts, we will separate out the business layer and create a framework that will handle it. Allowing you the developers to concentrate on the development tasks and the business people to handle the requirements.
We will enable every member of the team to be more effective. See you next time!