Of course, not every business work in the same way but most, especially worldwide, banking, finances and such, work in this fashion: Let’s say we need to create a system to adds a new customer, so we could create an application where the end-user enters the information, process it (and validate) and sends to the database. Sounds easy?. Well… no. It is the first version.
Inserting a customer, the easy way
It is not an enterprise application.
Let’s say the table customers has 100m of records?. It is a lousy query:
select * from customers.
So you are saying me a simple query could kill the performance of an entire database?. Yes, it is (a database could have some safeguards but they are not foolproof).
Now, it is the enterprise version:
What’s changed?. We splitted our system in two (three if we counted the database), one is the visual interface (web, aka SERVER 1) and other is the persistence (also logic, SERVER 2). We also split the database (SERVER 3) and we add a store-procedure.
Is it more code? yes and more bureaucracy.
Let’s say our application is exposed to the Internet, so our application could be hacked. Now, let’s say it is hacked. If it’s hacked, then the hacker could only access to the service supplied by the visual layer. He (or she) couldn’t, for example, delete the table customer unless there is a service that does that and only if the hackers know the service.
The Web Service fulfills two jobs, one is the security and other is the reusability. Any application (inside the intranet) could access the web service and consume it. This application doesn’t need to know how it is done, it simply calls the web service, and it does its job. So, in theory, it’s possible to change the database without affecting any system (thanks to the decoupling). About security, let’s say our Visual Server was hacked, the chances that the hacker hacks our web service is thin, and our hacker doesn’t know how to hack the database, he doesn’t even know if there is a database or not. As a plus, the web service could serve other purposes such as cache, load balance, and redundancy.
Usually, the web services are grouped together, it is called a Service Bus.
It’s not rare to find an enterprise that disallows any direct connection to the database unless it is done via a store-procedure. Why?. First, a store-procedure could be audited and reused. It also increases the security, and the DBA knows what is executed, so it’s possible to maintain the database model by understanding where it is used.
If you are worked on an enterprise company you could say: “meh, I already knew that” and yes, it is the point. Working on an enterprise is easy because it is repetitive (and it pays well). There is no surprise.
Note2: Don't kill the messenger.
Also published on Medium https://medium.com/cook-php/architecture-how-to-build-an-enterprise-application-9c649018e537
Yes, it is.
But what about microservice, AWS, the cloud, and such?
An Enterprise could use the cloud and microservice for some projects (for example, for the corporate portal) but not for an enterprise application. There are some exceptions but it is used with different rules, for example, AWS for Enterprise (EDP), it plays with different rules, it needs a contract, NDA, and other factors (signed SLA), it works more like outsourcing rather a cloud.