Aim to apply Domain Driven Design concepts and try to place only services that belong to the same bounded context in one repository e.g., Product (main service responsible for serving products) and Product Indexer (a service responsible for listening for product change events and indexing product data within search database).
triggered me and after searching this site I have found out that you are following a specific design pattern. Since I wasn’t familiar with Domain Driven Design, I have read about it. Moreover, It seems that the decoupling
of domain services and facades that you follow at Student.com results in a clean architecture. I have been trying to identify the DDD patterns on nameko-example repository while trying to figure out how I would apply DDD in a set nameko of microservices. I have understood that on nameko-examples, gateway acts as a facade. My question is if product & orders are two distinct domain services or under the same bounded context?
In general do you encourage to have a facade not strictly connected to a bounded context / nameko service ? Furthermore is it correct to define that rpc entrypoints act as Aggregate roots and orders/models.py act as a combination of Value Objects & Repository? (DDD theory). As you can understand, I am trying to find an analogy of Domain Driven Design with nameko-example project
Finally in a hypothetical case of an airtickets company, a domain service would be the ticket reservations service and another domain service would be a loyalty service. If my assumption is correct, then multiple facades can proxy requests to these services. Furthermore is any rule how big a database (e.g. number of tables) of domain service can be or the only constrain is the bounded context ?
I understand that my questions are very specific to DDD but I would be grateful I you could find some time and answer to me.
Thank you in advance,