[UK-AL]

Another benefit is getting database stuff out of your domain code, makes solving the business problem a lot cleaner.

In fact i just write a domain model, solve the problem, then write database adapter to persist the domain model. I always think about modeling the domain first, then persistence is an after thought. The persistence adapter can be done however you want, raw sql orm, nosql. So it's not really "abstracted away", it's just no the focus of the application.

Everything just plugs into the domain model.

[agentultra]

Your data is your domain. If you don't understand your data then you don't understand the problem. If there's a business rule for how that data is handled then it's most consistent to define it in the server that is purpose built to manage your data. Especially when it has built in facilities to constrain possible states.

I've seen too many programmer bugs to trust putting business logic outside of the DB. Separation of concerns here too just on different lines of concern.

[theptip]

> If you don't understand your data then you don't understand the problem.

That's a rather sweeping statement, that many in the industry do not agree with.

https://en.wikipedia.org/wiki/Domain-driven_design https://martinfowler.com/

> If there's a business rule for how that data is handled then it's most consistent to define it in the [db]

To be clear, you're proposing that all business rule validation should be implemented as stored procedures in the DB? One of my domain model aggregates consists of thousands of lines of code just enforcing business rules and constraints. Am I to put that all in the DB?

[agentultra]

> That's a rather sweeping statement, that many in the industry do not agree with.

And some who do

https://dataorientedprogramming.wordpress.com/tag/mike-acton...

I'm not going to appeal to authority here. I'm speaking from experience. We all know how source code gets over time with hundreds of programmers working on it. A clear, consistent specification of your data model, rules, invariants, and transformations is far more valuable than the abstract-soup of trying to model your business domain in source code. I think we can all agree that the less code there is to understand then the easier it is to verify it is correct.

Verifying the requirement that "when record A is written to the database then B is appended with the delta change if such and such is True" is guaranteed at the database level along with all of the other constraints on those relations. If it's nested in one of these rings behind an abstract factory somewhere it's harder to verify.

> Am I to put that all in the DB?

That's where I would start. But I'm not you and I don't understand the problem you're trying to solve.

My original point was that abstracting out the platform if you're not really concerned about switching platforms is a form of premature pessimization and a source of errors. If you control the platform, target the platform and don't bother with the abstractions.

[UK-AL]

A domain can become more about behaviour, intergration and business proccess. Rather than pure data.

I find most SQL languages are not particularly great for general purpose programming. Especially tooling for testing.

[agentultra]

I find relational algebra most useful for anything involving querying, validating, aggregating, and transforming data. SQL99 is by far one of the more useful implementations of it that I know about. And yes it does have limitations.

That's why most mature RDBMS servers ship with at least one procedural language. Though it'd be nice if there was an option to use OCaml or Haskell in PostgreSQL.

I'm not suggesting to throw out all your code and build your entire application in SQL. I'm just saying that if you control the database, use it, exploit it and don't abstract it out unless you absolutely have to (because you need to ship your application on-premises to clients who may run MySQL servers and others who run Oracle.

[sullenpaladin]

> if you control the database

That is a big if in the enterprise. It is getting better, but for most enterprise apps I have worked on, there is a db team that owns the db and you have to go through them for all changes.

Perhaps db abstraction can be thought of as an instance of Conway's Law.

[UK-AL]

It's depends on your domain. However most domains are just as much about behaviour and data then just data.

Bugs are just as likely to occur in the database programming language as they are in application logic.

In fact i think tooling around unit testing is far more mature in general purpose languages.

[diyseguy]

Agreed, when's the last time you saw a debugger for a stored procedure? There aren't any. If you want to debug such a thing, you've got to write a bunch of print statements like it was 1982

[diyseguy]

I've seen unbelievable messes developed as sprawling stored procedures. And, no unit tests, since no one ever wants to test database logic, they just assume it's gold.

[agentultra]

The same is true for the sprawling mess of Java interfaces and Factory patterns. Except now you have two sources of truth. Having worked with regulated clients and having to audit the entire stack it's much easier to to do with less code than more.

I've seen databases like that and similar teams that didn't take care with their change management.

Either way it's never pleasant to work with such systems.