Software Engineering is a growing discipline and has become a part of its natural progression with both new and improved development methodologies that emerge each year. Before starting a project, organizations should be conscious of the risks involved. So, what are the measures that need to be taken for software practitioners to achieve success; will selecting appropriate architecture helps ease the process? Certainly; architecture sets the very foundation for success in our application. Selecting the right architecture is important. If we choose the wrong architecture, we may have to rewrite a portion of the application. Therefore, if we plan ahead, we may have to only make changes to the architecture configuration that will alter the application behavior to achieve that success.
As we all know, there is no easy answer to software architecture. This is about making a decision, and hopefully the right one. This is about when, where, and why different architectural approaches and patterns make sense.
This article discusses when abstractions are justified and outlines the merits of various approaches for structuring applications with a pragmatic, real-world mindset. The discussion begins by outlining philosophies for thinking about architecture and considering the benefits of doing the simplest thing that could possibly work. Then we’ll consider an example architecture that is oriented for a Web application using Microsoft technologies. We will discuss the contexts where each makes sense.
Simplicity VS Complexity
When coming up with architecture, requirements and their risks need to be the main focus. We need to consider the trade-offs between simplicity and complexity. Which one do we use? It depends on several variables; such as timeline, budget, project size, and resources available for the project.
What is the priority here? Neither simple nor complex architecture is wrong; it depends on the situation and needs. The key is not to create an architecture that is more complex than warranted.
Real world architecture should be pragmatic, sensible. The reason to select a right architecture is to save money, time, and effort, not doing it to experiment, challenging yourself, or improve your resume. As a professional, we shouldn’t let our own interest, ego, or desire to improve ourselves push the architecture to the direction that is over-killed. Over-engineering waste money, effort and ultimately will cost us more time than we save.
Simplicity is one of the key points of the agile manifesto. There are a number of reasons to keep thing simple; they include:
- Get done sooner. The world around us is evolving and software is merely a representation of that world
- Easier to communicate – easier for a new team member to pick up
- Duplication is obvious – the need for refactoring are clearer and can be detected easily
- Less “prep time” – that is time to set up, training, necessary tooling, and so on.
Below is an example of a high-level picture of an application we do at Agile Tech. There is quite a bit more design work involved on the client side especially with more and more implementations are around Single Page Application (SPA) and patterns like Model View ViewModel (MVVM). Clearly, there is no such thing as one size fits all especially when it comes to architecture – if you like to adopt this style for your need, feel free to omit or add to the architecture based on your specific needs.
Let’s touch briefly on the layers illustrated in the above image:
- Presentation Layer
The Web API may be needed when you plan to expose your business logic using a Web service and/or to develop application more than a web-based application. For instance, the same methods can be exposed to other clients such as mobile client, tablets, etc. via Web API.
- Domain/Business Logic Layer
Implementing a separate business layer allows us to improve maintainability and testability. It also allows us to centralize and reuse common business logic methods. Additionally, this layer is responsible for handling long-running workflows; such as approval and notification process.
- Data Access Layer
The data access layer abstracts the logic necessary to access the database. This can be achieved by implementing Entity Framework (EF) that implements the Unit of Work Pattern with the DbContext. If you opted not to use EF, this layer can be implemented using ADO.NET. ADO is older, proven, and well-tested technology. From this layer, you can share the Business Entity/POCO (“plain-old” CLR objects) to return and get data for the Business Layer.
Here are the benefits of layered architecture presented above:
- Separate concerns
- Allow you to abstract away complexity
- Support testing
- Minimize dependency
- Loosely coupled that enables reuse
Software development is a complex activity that involves several tasks, disciplines, and phases that exhibit a high degree of variability. Upfront planning is the basis for predicting, measuring, and controlling problems and variations during the development lifecycle.
Critiques, comments, and questions are welcomed. If you don’t want your message to be publicized, you can reach me via email at