DPSA - Layering
Usually the ideation phase ends with a rough implementation plan with rough budgets as well at times. You should have a rough idea of the tech stack you would want to use as per the research and brainstorm that would go in building the core of your application. There are different set/combination of technologies that goes into the tech stack and these combination may change depending on various factors like:-
- Whether you are doing a POC project.
- How much scalable you want this to be.
- Skills that you have.
- How much time you have.
- What kind of infrastructure is available to you.
Factor your system so that artifacts that change at similar rates are together. - Foote and Yoder
In general, a typical web application would have below 4 layers.
- Business logic
Database, is probably the most important layer. It is also known as persistence layer as it remembers everything that you as an architect/product owner want the application to do and remember. There are 2 broad categories - SQL and NoSQL - as far as the fundamental difference is concerned. SQL is also known as Relational database. Each of them have their on pros and cons. Personally, I have preferred NoSQL for quite sometime. Depending on the type of data your database stores, it is further classified as operational, commercial, end-user etc. Growing old, as the database increases along with its importance, you may consider to maintain some kind of redundancy to prevent data loss or maintain availability - although this part would come much later into the stages of application like any other good application. The key decisions to make here are:
- What type of database you would want to have?
- Which data will need to be saved and in what format?
- How can schema design help query performance?
- What are some of the core important table?
Business logic, is a layer where you write your actual application code. This is where you make things work. This is probably the most complex part of your web application as it talks to database, supports user requests, runs jobs, react to internal and external events, and basically does what ever you expect your application to do. It’s important to have some kind of coding discipline right from day one as randomly written code can become a nightmare to maintain - anybody can understand this. This is the most apt moment you also start thinking about putting certain design principles in place so that the code gives best performance and it becomes easier to change or append the business logic whenever required. Key points to consider:
- Rough list of modules to implement as part of core.
- Design principles to follow, and a rough plan for the same.
- Initial draft of internal architecture diagram.
Application, aka presentation layer. This layer mainly deals with user requests and passing them on the the business logic in a manner that your business logic understands what to do - and then sending a formatted response back to the user. Key design decisions to make:
- API architecture
- Frontend templating engine
- Authentication and authorisation
Frontend, is the face of your application. This is what users will see and interact with. You should probably decide upon the frontend application framework you would want to use. There are quite a few factors which are important to consider while finalizing the frontend architecture. Of course, you can build your your own framework, for that matter you can even build your own operating system. Some of the important points of discussion here are:
- Framework of choice
- How would styling be done, how to leverage bootstrap?
- User session maintenance
- Browser compatibility?
- Mobile apps?
- Interface with backend
We shall go into the details of each layer in upcoming posts.