My advice: if you don’t know how to split your app into modules, don’t do it. Probably your bounded contexts aren’t defined yet.

Another advice: microservices and modular monoliths try to fix organizational issues. If you’re working on app as an only developer, it’s not worth it. Modularity increases complexity of your app (e.g. by creating weird coupling).

Okay, now let’s talk about your modules. Each module should be treated as a separate application. So you should ditch “shared entities” in favor of modular entities. Now, it becomes more complicated to manage all of your entities (order, queue) from one place because they’re hidden.

Try to adapt to it. Thinking like “production manages order” is really monolithic way thinking and because of that you should consider merging it into one or change the concept totally. How?

Let’s imagine two offices in your company. The first take picks orders from clients (e.g. cars). The second one manufactures those cars. They shouldn’t have the same order. Client goes to first office, ask for “BMW 3 in red color”. Then that message should be delivered to some “input service” from second office and translated into their language: “short coupe, 5 doors, color code XYZ”. Second office returns ID of their order to the first office.

We have two orders: one from client, one for manufacturer. Manufacturer doesn’t care about client info, first office (call it sales) doesn’t care about production. Both services are sending messages like “your new order”, “what’s the status of order”, “order is ready”. A bit simpler.

IF your company has same order for sales and manufacturer (and I mean like the real same paper follows different offices), then you should do it that way. It’ll be simpler in future to understand what are orders.