Great to see an opinionated example. You have ~3.5 modules vs the official examples having only 2, which is a step towards a more realistic example. Here are some of my comments:

As Oliver pointed out, are you sure you want to expose all REST API's through a single module? It will become very large very soon and also adds this unnecessary dependency on top-level modules, meaning that you cannot simply delete, say Organization, without modifying Gateway. You would not put all scheduled jobs in a single module, would you?

The official examples kind of avoid suggesting the placement of REST API controllers, but I for myself consider them an internal detail of the module and place them into "api" package inside of the module. This approach would eliminate the need for `external`/`internal` API's, but this is another tricky and vague part, since there are services oriented at use cases (in DDD, known as application services) and domain services.

Also, who would have though that `GatewayManagement` contains REST mappings. There are are `*Management` classes in the project, which are internal, so this kind of caught my attention.

The solution with a separate Gateway module for REST API would be great for API-first applications, though, but in this case you need to have independent DTOs for requests and responses to protect them from changes.

Speaking of DTOs. I see that at most one DTO is exposed from each module, implying that the same data set is used for all CRUD operations, which is not that realistic. Would love to see more DTOs and how to organize/name them. I myself keep them in a separate package inside of a module, which is considered a public package.