There's nothing the article's author is saying that's wrong, it's just there are additional considerations.
For example, how many applications are using this database? If it’s more than one, replicating business logic across multiple tech stacks introduces risk. Each stack may implement logic differently, and maintaining consistency becomes a challenge. Plus, each team will have its own priorities, so now you’ve added the complexity of coordinating delivery across teams.
A common solution is to centralize the business logic in a web service, allowing all applications to consume it uniformly. This works well - unless one of those applications needs to process large volumes of data. In that case, the web service can become a bottleneck. There’s also the organizational overhead: Who owns the API? Who supports it? Often that lies with "enterprise" web service teams, and they often have a policy of not embedding business logic in their APIs, so you may face pushback if you try to place it there.
If a client requires high-volume data access, a materialized view can be a great option. It’s performant and allows you to embed the necessary logic. It’s also helpful for clients that struggle to consume web services - most of that’s behind us, but there are always stragglers in the app portfolio. The downside? Materialized views require clients to have a database connection and a managed application account. There are also network constraints around where the client and database server reside.
There’s also a hybrid option: embed the business logic in a materialized view and expose the data via a web service. This satisfies "enterprise" web service teams that don’t want business logic in their APIs, while still centralizing logic and supporting high-volume access.
Ultimately, business logic can live in several places:
- Application
- Web Service
- View
- Hybrid: Web Service utilizing a View
Each option has trade-offs. The right choice depends on your architecture, performance needs, organizational structure, and organizational policies.
taylodl•4mo ago
For example, how many applications are using this database? If it’s more than one, replicating business logic across multiple tech stacks introduces risk. Each stack may implement logic differently, and maintaining consistency becomes a challenge. Plus, each team will have its own priorities, so now you’ve added the complexity of coordinating delivery across teams.
A common solution is to centralize the business logic in a web service, allowing all applications to consume it uniformly. This works well - unless one of those applications needs to process large volumes of data. In that case, the web service can become a bottleneck. There’s also the organizational overhead: Who owns the API? Who supports it? Often that lies with "enterprise" web service teams, and they often have a policy of not embedding business logic in their APIs, so you may face pushback if you try to place it there.
If a client requires high-volume data access, a materialized view can be a great option. It’s performant and allows you to embed the necessary logic. It’s also helpful for clients that struggle to consume web services - most of that’s behind us, but there are always stragglers in the app portfolio. The downside? Materialized views require clients to have a database connection and a managed application account. There are also network constraints around where the client and database server reside.
There’s also a hybrid option: embed the business logic in a materialized view and expose the data via a web service. This satisfies "enterprise" web service teams that don’t want business logic in their APIs, while still centralizing logic and supporting high-volume access.
Ultimately, business logic can live in several places:
- Application
- Web Service
- View
- Hybrid: Web Service utilizing a View
Each option has trade-offs. The right choice depends on your architecture, performance needs, organizational structure, and organizational policies.