Is there a community naming convention for common Domain/Feature-Based Packages for new projects?

[supsup]

Does anyone know of a good blog post, or github repo, going over the idea for new apps using Spring Modulith from the ground up with a base level naming convention to follow?

It seems like it would be beneficial to have some kind of standard recipe to use for new apps
so long term working with projects created using the pattern would be easier to jump between -- or is this a false idea, if so please go over why so i can better grok it!

for example like:

com.example.<yourAppName>.modules  
  /config  
  /auth 
         /config
         /audit
         /controller
         /domain
         /dto 
         /etc?

  /users
         /config
         /controller
         /domain
         /dto
         /etc?

  /companies
    ...
  /files
    ...

---

Given the above exaple sturcture is it best practice to combine AAA into one root package? Same question for users/companies or is there a better way to organize this from the ground up? I think it would be great to have a commuity standard (for new projects), for basic generic packages that most Spring Boot Applications use?

Thanks for any input and/or suggested reading.

===> UPDATE

these are the ones I've been using after learning more about feature based structure and using Spring Modulith :

com.example
├── account                   // User accounts, registration, profile management
├── security                  // Authentication, authorization, access control
├── content                  // Core content domain: articles, media, documents
├── i18n                       // Internationalization, translation, locale resolution
├── shared.events      // Cross-module domain events, integration events
├── activity                // User activity logs, audit trails, interaction tracking
├── notifications      // Email, in-app, and push notification logic
├── ... <project specific feature> 
├── ... <project specific feature n> 

Does this seem like an OK flow going forward or am I missing a key point here?

[odrotbohm]

The only guidance we give is: domain-specific, functional decomposition on the top level. Whether you use a second-level, technical decomposition is a matter of taste. I, personally, would rather avoid it until the module package gets too big, but I can see that teams are familiar with such decomposition and would like to see it for navigational purposes. That said, with a top-level functional decomposition approach, the number of types in such technical packages usually is rather low anyway.

In the example you give, your top-level packages don't sound very domain-specific in the first place. Unless you write a security application, security doesn't really form a domain module, does it? The same goes for i18n. A module named shared.events sounds a bit suspicious, too. I'd always try to avoid these kind of kitchen sink packages that folks might be inclined to throw in stuff just for the sake of sharing. Modules have API packages and can expose — and thus share — types with others anyway. Placing event types into those expresses which module owns them logically, and you're not creating that canonical place everyone has to depend on.

[supsup]

Thanks for the feedback, one question I have is how do you deal with global security issues if you are using spring security just put it in a config folder at the top level? like:

   config
      I18n.java
      AppSecurityConfig.java  
      PasswordEncoder.java

[odrotbohm]

I usually try to keep such global configuration as package-protected types in my root package, potentially even as static nested classes in the core application class. Alternatively, I've also seen folks declare a core or common module to put such code into, of course at the risk of creating such a kitchen sink as described above.

[supsup]

that makes sense, cool I will refactor and try that.