3 ms·

I’m torn on this subject. I’m all for stopping dumb bugs from occurring, But I can’t help but think in the general case this blog post is advocating for puttin

I’m torn on this subject. I’m all for stopping dumb bugs from occurring, But I can’t help but think in the general case this blog post is advocating for putting business logic inside my data layer. I am reminded of blog post I read some number of years ago that represented Pokémon type valances in his programs type system. Ironically, in the blog post itself there was a table showing how all the types interacted. If your data has complicated restrictions on what is valid, I feel it’s much better to serialize those restrictions in some database/config, as opposed to mucking up the physical structure of your program. That way when the rules inevitably change, you just have to change your config instead of rework your type system or database relations.

DaiPlusPlus 3y ago
> But I can’t help but think in the general case this blog post is advocating for putting business logic inside my data layer. That’s not a bad thing, provided the business/domain rules are invariant. > That way when the rules inevitably change, you just have to change your config instead of rework your type system or database relations. This is why it makes sense to do fast-moving projects in, say, TypeScript on NodeJS (or back-in-the-day: PHP) with a denormalized object-store (e.g. JSON blobs in Redis) and lots of E2E tests - while doing legacy-business stuff in, say, .NET and RDBMS. It’s disappointing how often people instead misinterpret the above to stereotype a platform as good or bad (well, PHP probably deserved it…). Right-tool-for-the-right-job and all.
- ParetoOptimal 3y ago
  Right tool for the job is a safe bet for and path to low, mediocre, and sometimes above average quality that has a hard ceiling. Integration complexities can be ignored often since they are typically longer term considerations.
ParetoOptimal 3y ago
The answer here is to have dumb types to store the data in, smarter domain types correct by construction, and only write business logic on the domain types.

DaiPlusPlus 3y ago

> But I can’t help but think in the general case this blog post is advocating for putting business logic inside my data layer. That’s not a bad thing, provided the business/domain rules are invariant. > That way when the rules inevitably change, you just have to change your config instead of rework your type system or database relations. This is why it makes sense to do fast-moving projects in, say, TypeScript on NodeJS (or back-in-the-day: PHP) with a denormalized object-store (e.g. JSON blobs in Redis) and lots of E2E tests - while doing legacy-business stuff in, say, .NET and RDBMS. It’s disappointing how often people instead misinterpret the above to stereotype a platform as good or bad (well, PHP probably deserved it…). Right-tool-for-the-right-job and all.

ParetoOptimal 3y ago
Right tool for the job is a safe bet for and path to low, mediocre, and sometimes above average quality that has a hard ceiling. Integration complexities can be ignored often since they are typically longer term considerations.

ParetoOptimal 3y ago

The answer here is to have dumb types to store the data in, smarter domain types correct by construction, and only write business logic on the domain types.