Return to Answer

Copy edited (e.g. ref. <http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol>, <http://en.wikipedia.org/wiki/Transport_Layer_Security>, <http://en.wikipedia.org/wiki/SOAP>, and <https://en.wikipedia.org/wiki/Object-oriented_programming>). [(its = possessive, it's = "it is" or "it has".)]

Source Link

edit approved Sep 18, 2019 at 23:43

Peter Mortensen

Network Service Framework to provide high level httpHTTP/sslSSL/soapSOAP protocol implementations
Repository/ORM/DAO Framework to provide persistence.
Data Manipulation Frameworks to provide tools for working with data.
Process/Threading/OS Framework to provide access to osOS resources such as multi-tasking, the file system, memory, gpuGPU compute, expansion cards, etc...

Another technology. Each technology present in the application decreases the likely-hood that any given programmer can read, understand, and make wise design choices for that technology mix.
A language using a different programming paradigm. It is far too easy for non-experts to try and force their own imperative/functional/oo/etc, functional, OO, etc... perspective onto it, which often leads to less than stellar results.
An API. Which must be maintained like any other class in the code base. It also means that the database is providing a non-generic interface. This makes it harder to both replace the database engine itself, and to transparently apply generic behaviour such as in memory caching.
An artefact. Which must be versioned, tested, and deployed. This can be done, but databases are living artifacts requiring a different approach. You cannot usually just delete the original, and replace it. Often a careful orchestration of changes over-time are needed to migrate the system to the desired state.

ItsIt's a bad practice, because the database and business logic operate on different shearing levels.

If the business logic is distributed across the shearing layers, particularly into a slower and longer lived layer, it will generate resistance to change. This is not necessarily a bad thing. AfterallAfter all, the only database that has zero business logic in it is a triple store.

But letslet's think the unthinkable, how would you maintain business logic distributed across several languages?

Network Service Framework to provide high level http/ssl/soap protocol implementations
Repository/ORM/DAO Framework to provide persistence.
Data Manipulation Frameworks to provide tools for working with data.
Process/Threading/OS Framework to provide access to os resources such as multi-tasking, the file system, memory, gpu compute, expansion cards, etc...

Another technology. Each technology present in the application decreases the likely-hood that any given programmer can read, understand, and make wise design choices for that technology mix.
A language using a different programming paradigm. It is far too easy for non-experts to try and force their own imperative/functional/oo/etc... perspective onto it, which often leads to less than stellar results.
An API. Which must be maintained like any other class in the code base. It also means that the database is providing a non-generic interface. This makes it harder to both replace the database engine itself, and to transparently apply generic behaviour such as in memory caching.
An artefact. Which must be versioned, tested, and deployed. This can be done, but databases are living artifacts requiring a different approach. You cannot usually just delete the original, and replace it. Often a careful orchestration of changes over-time are needed to migrate the system to the desired state.

Its a bad practice because the database and business logic operate on different shearing levels.

If the business logic is distributed across the shearing layers, particularly into a slower and longer lived layer, it will generate resistance to change. This is not necessarily a bad thing. Afterall the only database that has zero business logic in it is a triple store.

But lets think the unthinkable, how would you maintain business logic distributed across several languages?

Network Service Framework to provide high level HTTP/SSL/SOAP protocol implementations
Repository/ORM/DAO Framework to provide persistence.
Data Manipulation Frameworks to provide tools for working with data.
Process/Threading/OS Framework to provide access to OS resources such as multi-tasking, the file system, memory, GPU compute, expansion cards, etc...

Another technology. Each technology present in the application decreases the likely-hood that any given programmer can read, understand, and make wise design choices for that technology mix.
A language using a different programming paradigm. It is far too easy for non-experts to try and force their own imperative, functional, OO, etc... perspective onto it, which often leads to less than stellar results.
An API. Which must be maintained like any other class in the code base. It also means that the database is providing a non-generic interface. This makes it harder to both replace the database engine itself, and to transparently apply generic behaviour such as in memory caching.
An artefact. Which must be versioned, tested, and deployed. This can be done, but databases are living artifacts requiring a different approach. You cannot usually just delete the original, and replace it. Often a careful orchestration of changes over-time are needed to migrate the system to the desired state.

It's a bad practice, because the database and business logic operate on different shearing levels.

If the business logic is distributed across the shearing layers, particularly into a slower and longer lived layer, it will generate resistance to change. This is not necessarily a bad thing. After all, the only database that has zero business logic in it is a triple store.

But let's think the unthinkable, how would you maintain business logic distributed across several languages?

Source Link

created Sep 16, 2019 at 10:07

Kain0_0

16.3k
19
40

To write software requires that you tightly couple to a technology.

At the very least to the runtime environment provided by the programming language being developed within.

More generally though you will find that your micro-service is tightly coupled to several technologies:

Network Service Framework to provide high level http/ssl/soap protocol implementations
Repository/ORM/DAO Framework to provide persistence.
Data Manipulation Frameworks to provide tools for working with data.
Process/Threading/OS Framework to provide access to os resources such as multi-tasking, the file system, memory, gpu compute, expansion cards, etc...

And that is to make a bare-bones micro-service.

Stored procedures

A stored procedure is simply another technology that you could choose to use or not use. It does not magically make your code monolithic, or micro.

What it is though is:

Another technology. Each technology present in the application decreases the likely-hood that any given programmer can read, understand, and make wise design choices for that technology mix.
A language using a different programming paradigm. It is far too easy for non-experts to try and force their own imperative/functional/oo/etc... perspective onto it, which often leads to less than stellar results.
An API. Which must be maintained like any other class in the code base. It also means that the database is providing a non-generic interface. This makes it harder to both replace the database engine itself, and to transparently apply generic behaviour such as in memory caching.
An artefact. Which must be versioned, tested, and deployed. This can be done, but databases are living artifacts requiring a different approach. You cannot usually just delete the original, and replace it. Often a careful orchestration of changes over-time are needed to migrate the system to the desired state.

Each of these is a real cost. In some cases the cost is justifiable, in others it is not.

You would be paying almost the same set of costs by hosting a scripting engine. The sole reduction is that you could choose the same programming paradigm as the host language.

Business Logic

Moving business rules into the database is bad practice. Just not because of stored procedures.

Its a bad practice because the database and business logic operate on different shearing levels.

A database in a mature applications can be in use for decades. Generally these systems will have the engine periodically updated, but the database itself was migrated. It was not killed and rebuilt from the start. There is no reason a micro service cannot be equally so long lived.
Contrast decades against how quickly business rules change. In my experience an old business rule is perhaps a few years old, most however change quickly, and you can never tell which one will change next. A new requirement from a regulator, an old product being decommissioned, changes to the letter head, changes to how many employees report to a boss, etc, etc, etc...

If the business logic is distributed across the shearing layers, particularly into a slower and longer lived layer, it will generate resistance to change. This is not necessarily a bad thing. Afterall the only database that has zero business logic in it is a triple store.

The mere act of specifying a table schema is moving business logic into the database.

Architecture

You are contending with using the appropriate tool for the appropriate problem, without needing too many tools, nor making it too hard to solve, in order to make and maintain a solution.

This isn't easy.

But lets think the unthinkable, how would you maintain business logic distributed across several languages?

A catalogue... so that each business rule implementation can be tracked and maintained.
Tests... that could be used against each business rule regardless of where and how it was implemented.
A reference implementation.. so that when discrepancies are found, a source of truth exists (or at least a source of debate).

But this has a cost too.

Is it better to allow the business rules to have many implementations? That can each take advantage of the team skills, and framework provisions, but needing tight quality controls to ward off having many small vagaries?
Or is it better to have a single source of truth, written in a single language? Arguably cheaper to implement, yet also a single source of failure, itself a monolithic component that resists change in the face of different platforms, frameworks, or as yet to be invented tools?