Modular Monolith: Domain driven design, need help.

I am building a SaaS with various business domains through modular monolith (microservice through code constraints rather than infrastructure constraints).

Example modules that users can subscribe to

I am building a SaaS with various business domains through modular monolith (microservice through code constraints rather than infrastructure constraints).

Example modules that users can subscribe to are Human Resources (HR), or Customer Resource Management (CRM). Below are initially how I would design it.

Public API Layer * Entirely entity based. * CRUD for employee entity, product entity, etc. * Not sure how I can scope a public API to a specific domain. * I will be using GraphQL for all CRUD operations * Auth endpoints will be using REST.

Service Layer * Domain model based on modules, HR and CRM. HR has specific entity like employee. * There will be many entities that need to be shared through various domains, like product. * Does product need to be its own service? Its odd then to have services based on entities and some based on domain. * I have other domains like billing that aren't an actual module that a user can subscribe to. Ex: Billing is part of every user. * Will I need a utils service domain for data managed solely by the SaaS and not users? Ex: list of countries, what modules are available (HR, CRM), what application settings are available. * Am I overcomplicating this? Just do everything based on an entity and call it a day. One entity = one service.

Data Layer * Using PostgreSQL. * I do not see much info on data modeling in terms of modular monolith. * I am thinking single database because it is still a monolith, but model it as a microservice. * Where I would normally have FK, I don't have them. I really can't seem to conceptualize this. I have an orders service. An order can have many products. But products is its own service. Adding a FK between orders table and products table is how I would it in traditional monolith. But now on the database layer, the orders table and products are technically tightly coupled. * Another problem I had, was dealing with supertype/subtype that span different domains. So the whole domain modeling wouldn't work well. * A customer and employee are actually the same entity. That entity is a party. Customer and employee are subtytpes. Party is supertype. But customer is within CRM domain and employee is within HR domain. The goal is do encapsulation well through code constraints, so when you actually have to do microservices through infrastructure it becomes a seamless transition. I just need advice on generally how to handle domain modeling with modular monolith at each layer.