DEV Community

Cover image for Architecture: how to build an enterprise application

Architecture: how to build an enterprise application

Jorge Castro
You are free to believe in whatever you want to, me too. So, stop preaching your religion, politics, or belief. Do you have facts? Then I will listen. Do you have a personal belief? Sorry but no.
Originally published at Updated on ・4 min read

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.*5GS4TrH-btCk_VV69UvF1A.jpeg
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.
Enter fullscreen mode Exit fullscreen mode

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.*NsY-So0ybSOjtJ_uFi0nNA.jpeg

  • 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*0ck3sTkzrVPkdLQS-AJ4Cw.jpeg

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.*B5x_7n2ckjwzS1rSHLYMoA.jpeg

  • 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 knows 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.


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

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.

Discussion (3)

vekzdran profile image
Vedran Mandić

Well put. Honestly, I like the monoliths I worked on and would again start (even on my own) with simple monolith which solves the aimed problems securely with a dose of scalability and with an ability to 'eject' or offload to microservice design if needed. And that would be through a bus or messaging system. I guess a typo in "If you are worked on an enterprise". Thanks for the writeup and attached images which help understand better what your telling.

jorgecc profile image
Jorge Castro Author • Edited


About Microservice, Microservice is for the cloud; we could buy a small instance with its own web server and database, it is microservice, however and in general, it's not suitable for an enterprise environment.

About scalability, microservices are not scalable. You can't start a microservice architecture, and magically it is scalable. It is not how it works, and it is part of the myth of microservice.

We achieve scalability by using load balancing, clusters and so on, the same than with monolith. We use microservice because of decoupling and because it's easy to modify and to implement. However, we already are doing it with SOA (Service Oriented Architecture).

Let's say we decide to move from SOA to microservice. It means we need more server (microserver), each one using its own instance. This generates an over-head because we aren't increasing the number of machines but the number of instances using the same machines, then we need to orchestrate each microservice. Also, each micro-instance requires maintenance.

chrisrprince profile image
Christopher Prince

I think you missed the core concepts of an Enterprise Application. This is more of a client-server / web app monolith for a silo'd business. The tiered architecture and enterprise scope are missing. In a traditional enterprise application, the services of the tiers can be deployed and accessed by multiple interfaces, in addition to the presence of the enterprise scoped information systems

Forem Open with the Forem app