Domain Driven Design and subsystems

I'm working on architecting a project with Domain Driven Design. (Of course, I am not conforming to the exact definition of DDD pragmatically, but only apply where it fit). And come across a dilemma

Imagine a laptop shop, you would have a customer-facing frontend with landing pages, product pages and cart, etc. While the internal staff have a different frontend to check on product stocks, etc. And a third-party transport service frontend to handle delivery.

Although different use cases with different UI and users, at the end of the day the data is from the same source. So a monolithic backend API is a valid solution. Let's say we provide 3 api group for the 3 Frontends:

/api/customer/...

/api/internal/.....

/api/partner/....

The problem is the structure of the domain. Let's say we have 4 domains: Auth, Order, Product and Branch (unique to Internal system). Initially i thought mirroring the api structure is a good way:

domain
-----Customer
----------Actions
---------------Auth
---------------Order
---------------Product
----------DTOs
----------Enums
---------------Auth
---------------Order
---------------Product
-----Internal
----------Actions
---------------Auth
---------------Order
---------------Product
---------------Branch
----------DTOs
----------Enums
------Partner
----------Actions
----------DTOs
----------Enums
------Shared
----------Actions
----------DTOs
----------Enums

Treating the type of user as a domain group But upon some prototyping. I find that treating the type of user as Bounded Context could make more sense.

Consider the View Order feature. A customer can view his orders, the staffs can also view the orders, and the delivery company must also view (at least a portion) of the assigned order that they are delivering.

So the Action GetOrder should now be placed at the "Shared" domain. Now, some future change to the order would mean we working at 4 different folders, or more, instead of keeping the Order concern close as DDD intended.

Which means, the following architecture could make more sense:

domain
-----Order
----------Actions
---------------Customer
---------------Internal
---------------Partner
---------------Shared
----------DTOs
----------Enums
---------------Customer
---------------Internal
---------------Partner
---------------Shared
-----Product
----------Actions
---------------Customer
---------------Internal
---------------Partner
---------------Shared
----------DTOs
----------Enums
-----Branch
----------Actions
----------DTOs
----------Enums
-----Shared
----------Actions
----------DTOs
----------Enums

This architecture now treat the Modules more like a Bounded Context.

However, this architecture hierarchy would be completely separate from the Application architecture hierarchy, since the API endpoints is still grouped by user type.

If it was you what would you prefer?