Standardize modules stucture

[fedekunze]

Summary

Standardize folders and location of files across SDK modules.

Problem Definition

This allows for other features to be created from this standard (eg #4191, Swagger file autogenerated from module, etc).

Some modules don't follow the structure as described by @alexanderbez

x/
├── alias.go
├── app.go
├── module.go
├── client/
│   ├── cli/
│   └── rest/
|       └─ swagger.yaml                  // defines the internal types and endpoints
├── exported/                            // exported internal interfaces
├── genesis.go
├── handler.go
├── keeper/
│   ├── keeper.go
│   ├── keys.go
|   └── querier.go  
├── invariants/
└── types/
     ├── tags.go
     ├── msgs.go
     ├── keys.go
     └── expected_keepers.go

Proposal

Ensure modules follow and comply the proposed standard tree. Maybe add check with CI

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[alexanderbez]

Looks good to me! Although I think we should rename app.go to abci.go 👍

[shanev]

This looks reasonable to me, but a couple questions:

• app.go could get confused for the top-level app.go. Maybe abci_app.go?
• What exactly is the purpose of /exported?
• Would /keeper and /querier have a file for each stored type?

i.e: for a module named "claim":

x/claim
├── keeper/
    └── claim.go
├── querier/
    └── claim.go
└── types/
    └── claim.go

• What is in expected_keepers.go?

Also, with this layout, a simple dapp could be implemented as a single module. When is it preferable to go with multiple modules over a single one? I'm guessing if a module provides general functionality and could be re-used, then it should be it's own thing.

[alexanderbez]

@shanev

1.) I agree, hence I recommended abci.go as you're fulfilling ABCI methods for that module.
2.) /exported contains exported types (mainly interfaces) that other module's /expected_types imports -- it's to keep code DRY and prevent varying modules having to redefine a common interface (e.g. Validator).
3.) This isn't a bad idea, but I would not say it's necessary.
4. expected_keepers is a way for a module to define the contract (interface) it's keeper and other components needs without having to the import a module directly (e.g. using the validator interface defined in staking without having to import staking). This goes hand-in-hand with exported

Also, with this layout, a simple dapp could be implemented as a single module. When is it preferable to go with multiple modules over a single one? I'm guessing if a module provides general functionality and could be re-used, then it should be it's own thing.

This depends on the context of the app/module. Ideally, all modules should as extensible and modular as possible. Even if an app could be implemented using a single module -- it should be a module.

[alexanderbez]

Updated. Querier will exist in keeper/ and it's types constructors will exist in `types/

[alessio]

We should use Golang's special internal package to hide module's internal structure and all those types and functions that are not meant to be exported rather than instead of an exported package.

[alexanderbez]

app.go => abci.go
handler.go and genesis.go should not live in internal.

[fedekunze]

Closing via #4618.

Please refer to the updated module spec for the most updated version of the standard.