docs: fix recommended folder structure (#20907)

docs/build/building-modules/11-structure.md

@@ -50,29 +50,29 @@ x/{module_name}
 │   ├── keys.go
 │   ├── msg_server.go
 │   └── querier.go
-├── module
-│   └── module.go
-│   └── abci.go
-│   └── autocli.go
-│   └── depinject.go
 ├── simulation
 │   ├── decoder.go
 │   ├── genesis.go
 │   ├── operations.go
 │   └── params.go
-├── {module_name}.pb.go
-├── codec.go
-├── errors.go
-├── events.go
-├── events.pb.go
-├── expected_keepers.go
-├── genesis.go
-├── genesis.pb.go
-├── keys.go
-├── msgs.go
-├── params.go
-├── query.pb.go
-├── tx.pb.go
+├── types
+│   ├── {module_name}.pb.go
+│   ├── codec.go
+│   ├── errors.go
+│   ├── events.go
+│   ├── events.pb.go
+│   ├── expected_keepers.go
+│   ├── genesis.go
+│   ├── genesis.pb.go
+│   ├── keys.go
+│   ├── msgs.go
+│   ├── params.go
+│   ├── query.pb.go
+│   └── tx.pb.go
+├── module.go
+├── abci.go
+├── autocli.go
+├── depinject.go
 └── README.md
 ```
 
@@ -80,11 +80,9 @@ x/{module_name}
 * `exported/`: The module's exported types - typically interface types. If a module relies on keepers from another module, it is expected to receive the keepers as interface contracts through the `expected_keepers.go` file (see below) in order to avoid a direct dependency on the module implementing the keepers. However, these interface contracts can define methods that operate on and/or return types that are specific to the module that is implementing the keepers and this is where `exported/` comes into play. The interface types that are defined in `exported/` use canonical types, allowing for the module to receive the keepers as interface contracts through the `expected_keepers.go` file. This pattern allows for code to remain DRY and also alleviates import cycle chaos.
 * `keeper/`: The module's `Keeper` and `MsgServer` implementation.
     * `abci.go`: The module's `BeginBlocker` and `EndBlocker` implementations (this file is only required if `BeginBlocker` and/or `EndBlocker` need to be defined).
-* `module/`: The module's `AppModule` implementation.
-    * `autocli.go`: The module [autocli](https://docs.cosmos.network/main/core/autocli) options.
 * `simulation/`: The module's [simulation](./14-simulator.md) package defines functions used by the blockchain simulator application (`simapp`).
 * `README.md`: The module's specification documents outlining important concepts, state storage structure, and message and event type definitions. Learn more how to write module specs in the [spec guidelines](../spec/SPEC_MODULE.md).
-* The root directory includes type definitions for messages, events, and genesis state, including the type definitions generated by Protocol Buffers.
+* `types/`: includes type definitions for messages, events, and genesis state, including the type definitions generated by Protocol Buffers.
     * `codec.go`: The module's registry methods for interface types.
     * `errors.go`: The module's sentinel errors.
     * `events.go`: The module's event types and constructors.
@@ -94,3 +92,8 @@ x/{module_name}
     * `msgs.go`: The module's message type definitions and associated methods.
     * `params.go`: The module's parameter type definitions and associated methods.
     * `*.pb.go`: The module's type definitions generated by Protocol Buffers (as defined in the respective `*.proto` files above).
+* The root directory includes the module's `AppModule` implementation.
+    * `autocli.go`: The module [autocli](https://docs.cosmos.network/main/core/autocli) options.
+    * `depinject.go`: The module [depinject](./15-depinject.md#type-definition) options.
+
+> Note: although the above pattern is followed by most of the Cosmos SDK modules, there are some modules that don't follow this pattern. E.g `x/group` and `x/nft` dont have a `types` folder, instead all of the type definitions for messages, events, and genesis state are live in the root directory and the module's `AppModule` implementation lives in the `module` folder.