4 ms·
To me, good modularity at the data layer doesn't mean abstracting away Postgres or even SQL. To me, it means having a separation of concerns between loading dat
by lukeramsden 4y ago
To me, good modularity at the data layer doesn't mean abstracting away Postgres or even SQL. To me, it means having a separation of concerns between loading data, writing data, and _processing data as domain objects_. Don't have your core business logic operate over database rows, but in-memory objects. You can test the loaders/writers separately to your actual logic at that point.
- cube2222 4y ago> Don't have your core business logic operate over database rows This is the part where I don't agree, as SQL is very expressive, and needlessly loading data to your app is also not performant (making the transition to something else required sooner). I think writing parts of your business logic in SQL that make sense to be written in SQL is just fine. If you only use it to load and write entities, then that is basically a glorified KV store.