Really solid walkthrough of the shared domain model pattern. The squirrel approach where SQL stays as actual SQL files instead of getting abstracted away is refreshing, especially since it lets you use full-text search without fighting an ORM layer. One thing I've wrestled with in similar setups is deciding when the mapping functions from SQL types to domain types actually earn their keep versus when they're just ceremony. In my experienc the abstraction pays off once queries start returning partial or joined data rather than full table rows.
Yeah, the defining domain model is always a challenge and I think depends on the project. In my case, on a project I was working recently, I defined in the shared domain model entities that will go to the outside (eg in the API responses), so I can map various SQL record types to the domain model and only define JSON encoding/decoding for a small subset of data.
But on the backend or in tests, it's usually just fine to use SQL generated types IMO.
Really solid walkthrough of the shared domain model pattern. The squirrel approach where SQL stays as actual SQL files instead of getting abstracted away is refreshing, especially since it lets you use full-text search without fighting an ORM layer. One thing I've wrestled with in similar setups is deciding when the mapping functions from SQL types to domain types actually earn their keep versus when they're just ceremony. In my experienc the abstraction pays off once queries start returning partial or joined data rather than full table rows.
Yeah, the defining domain model is always a challenge and I think depends on the project. In my case, on a project I was working recently, I defined in the shared domain model entities that will go to the outside (eg in the API responses), so I can map various SQL record types to the domain model and only define JSON encoding/decoding for a small subset of data.
But on the backend or in tests, it's usually just fine to use SQL generated types IMO.