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.

What is the problem with this version?

• Security. It lacks security. What if the visual interface is hacked? Then, the whole database could be exposed. So it is a big no.
• Persistence. It assumes that we are the owner of the database. We (as developers and architects) are part of the business, but we don’t own all the business. A proper company has DBA, and they are the true owner of the database so that they can grant (or deny) us permission. Also, we are exposing the database directly and what if a query overloads the database?. Most databases could hold a significant demand but at the expense of the performance. A bad query could slow the entire database.

What is a bad query?.

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).

• The DBA could audit the queries that are running at runtime but it is a reactive job, the queries must be reviewed proactively.

• This system lacks reusability. What if other system wants to access the same table and do the same job?. We should build a new table every time, we should re-use the table and the connections to it.

Now, it is the enterprise version:

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.

Why we need to do that?.

I explain.

• Separating the Visual Server (Server 1).

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.

• Web Service (Server 2)

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.

• Database (Server 3)

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.

Note:

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

But, it is a monolith application.

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.

---