We have looked at a broad range of topics this season. However, it is time for us to tackle the middle tier architecture. Thus, we need to consider process steps (or flow) and look for commonality among the problems we solve. This area is not the most obvious to architect. However, it is an essential piece of the final solution.
Middle Tier Architecture As We Go
One of the challenges with the middle tier architecture is that it tends to get built over time. We design the front and back ends of the application. However, little time is spent on business rules and core logic. Data items and visual controls are more concrete for us to work with. The logic and problem-solving that makes up most of the middle tier tend to be nebulous.
While that “squishy-ness” of the middle tier can be a challenge, I do not think we avoid that architecture. It just tends to be less noticeable. Of course, once you start to dig into the business logic, you will see all manner of pieces that can be used to build out an architecture.
Your Personal Framework
Generally speaking, the middle tier architecture is a framework for your solution. This area often contains the heart of the solution, and many of the critical problems solved for your users. When you think about it, the front end displays your solution; the back end stores it, and then the middle is where the work gets done. That alone should get you thinking that more time should be spent focused on the design and architecture of the middle layer. When you do things right, the resulting solution may be viable to spin off as a commercial product.
Avoid Duplication
The best outcome of middle-tier architecture is the avoidance of duplicate code. That is what typically happens when we allow this tier to grow organically. It is not until we see a lot of repeated code that we step back and refactor. That is a costly approach in time and effort, so it is worthwhile to plan and avoid this situation.
