In this article I’m gonna weight down the importance the separation of software in components and layers of functionality. When a programmer starts a new piece of software, he could choose from multiple approaches to pick. The choice depends on several factors often requested from outside. Such may be – project complexity, team size, product specification, platform or framework of choice.
Simple Projects
This is the case of small and simple apps and games, implemented by single developer, experimenting with new framework, programming language or idea. There is no real need of diving into complexity. One of the keys to create Minimal Viable Product of an idea is not to over-complicate stuff and keep it simple and stupid while it doesn’t makes sense.
Monolithic /Single/ Big Application
If you have picked up to organize your software into one big app (having medium size requirements), it makes sense to organize things in Software Layers. These could be the MVC, MVP or MVVM design patterns. You will have a folder with data models, a folder with user interface code, a layer of true, custom business logic and layer of the generic operations on data models (CRUD) targeting some information storage or software.
Component Based Frameworks and Libraries
There are a lot of possibilities to use or create components – with every Programming Language and Platform. Java has – Vaadin, GWT, Android has old fashion views or Jectpack Composables. The Components based libraries and frameworks on the Web are also abundant – Web Components, ReactJS, View.js, Angular, Flutter [read more about flutter in our blog].
Software Pluggability
Software pluggability is a key aspect for its success. Generally speaking it must have both good functionality layer separation and component feature separation.
As an API – developer is the main user
Programming Languages and nothing more than a Components for abstracting above the machine. When the level of abstraction is small the components are targeting only a specific level of the layers of the code and are not self-sufficiently reusable. Good libraries bring the component from the bottom to the top of its usage. Such programmatically pluggable components are the Ad Views, the package of Cloud Based Libraries and Services like Firebase and Amplify and so on.
Micro Services – As a Service – for dev/ops or system administrator
Software is implemented as a Service in many cases with exposure on:
- HTTP,
- Socket with custom protocol
- Some Messaging Platform like Kafka,
Software Layers could potentially be plugged to other software without code, but with configuration. The Developer must integrate the components but if raised to visually interface, could bringing programming to whole another non-dev level.
The Micro Services require a DevOps specialist to wire the components together. As I heard in one lecture – the library choices in the code are often on second or third level – after the ones from the Runtime Platform or Service.
Components closer to the End User
If a service is exposed over HTTP, it is potentially pluggable with little, or even with no programming. If it has full HTML front-end wrap, it could be embedded in whatever places with simple iframe snippet. Examples of that are – maps, ad banners, also the videos from the online platforms, comments, likes, statistic sections and more. There are also Content Management Systems that offer embedding of partial HTML components within the content from the user wrapped up nicely – again with no code.