This my second post on the 100 days of learning challenge I set myself over the weekend. You can read more about this years goals here.
I'm going the explore the things to consider when planning a new project.
As a web application developer I make a lot of decisions each day. The art of programming is making decisions ahead of time and writing the code to deal with the potential decisions the program should know how to make depending on the interactions of the user or other programs.
Some examples:
Decide if the user is logged in
Decide what data they would like
Decide if a button is clicked
Decide if another program needs data from a database
These are the micro decisions that allow the program to run.
As a builder understands the formation of the bricks and the grain of the wood, the engineer understands why the walls are there and the importance of the angle the frames join at.
This is the same for application development. I have to decided to look at the decision making process for making the bigger picture decisions that a software engineer or architect may have to make.
I have decided to make a data driven application that responds quickly to user interaction.
There are an infinite number of ways to make a program ,the five following patterns are some of the most common:
This is a very common approach and found in a number of the larger frameworks for application development. The code is arranged so the data collected at the top tier and works it’s way down to the database.
i.e. form data from website → send to server → process the data → add to database.
It’s common for teams for developers to work on different tiers as each layer is independent from the layers below it.
As the name suggests this pattern centers on responding to events, there is normally one main unit that receives data and then delegates it to a separate module that then handles the particular data type. This type of handoff is considered to be event generation and processing.
This type pattern is often used in interactive web documents that deal with events in the browser like mouse clicks or key strokes.
There are many applications that do the same operations over and over again in slightly different ways depending on the data and the task involved. The Micro kernel architecture is designed to deal with this scenario.
It separates a minimal functional core from extended functionality and customer-specific parts. Meaning the program follows a basic set of rules which are then expanded upon for variations or additions of the core rules.
i.e. The rules that govern a sales transaction, receive funds and exchange goods all follow the same basic pattern, but the type of payment and goods exchanged may differ. This would be implemented in the extension of the micro kernel.
The micro service architecture is designed to help developers avoid making programs too large and hard to maintain.
Instead of building one big program, the goal is to create a number of different smaller programs and then create a new small program every time a new feature is requested.
i.e. Netflix uses this approach to separate all the components of the interface. Each section is its own separate entity that is bound together by the interface itself.
Many applications are built around a database. When a database is under stress and can’t keep up with the constant challenge of writing a log of the transactions, the entire website may fail.
The space-based architecture is designed to avoid functional collapse under high load by splitting up both the processing and the storage between multiple servers. The data is spread out across the nodes
just like the responsibility for servicing calls.
i.e This is the architecture behind what many of us have come to know as cloud computing.
Layered (n-tier) architecture
Pros:
Cons:
Event-driven architecture
Pros:
Cons:
Micro kernel architecture
Pros:
Cons:
Micro services architecture
Pros:
Cons:
Space-based architecture
Pros:
Cons:
Decision: Event-driven architecture
I have chosen this pattern as it will allow the application to respond quickly to events and allow for easier maintainability for a relatively small application.
There may be some difficulty handling errors as well as handling many events at once. There may be a case for using a Layered style such as MC which is a common implementation of the design pattern which would provide more reliability as well as providing a structure for the sub-modules that handle the events.
Through the course of implementing the plan there were many times that the plan had to adapt to the growing requires of the program. Often during the actual development many small adjustments had to be made to ensure the project was a success.
This is way to perform iterative planning allowing the main overall plan to flex and recalibrate in order to achieve the end goal that the plan was originally devised to achieve.
Here is an example iteration:
Using a event driven architecture implement a question forum.
Develop a page that presents user questions and answers together.
Ask the right questions.
Is the best way to handle the data?
A layered approach may be more applicable to handle the processing logic of the data.
Begin to develop with MVC pattern
Start lifecycle again
These iterations are important and your end result will most like end up a combination of architectural patterns. The important thing is knowing how and why you should be using them.
Happy Coding!
