Proof of concept for breaking module packages per responsibility

[robert-zaremba]

Summary

Ref: discussion in discord #core

Problem Definition

The design of having a types package, which contains all types for given module, is a bit odd:

1. it doesn't encapsulates the ownership and concerns properly
2. looks hacky

Proposal

Define packages per responsibility (domain): keeper, msg, client, dal (data access layer).

This approach (not having a generic types package) would require from us that we focus more on interfaces: usually we have an interface and interface implementation, and breaking packages by responsibility makes it easier to also have a clear interface separation (as we have with crypto and crypto/sha256 and crypto/md5 ...).

---

For Admin Use

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

[alexanderbez]

ACK. types, common, util, etc...are all anti-patterns and we should avoid them. I wouldn't propose we enforce any exact hierarchy on specific modules, only that they don't use a vanilla generic pkg. This should also be done in by 0.41 as we're gearing up towards a 1.0 stable release hopefully soon.

[aaronc]

#7093 and #7122 might be relevant to reorganizing modules. These would allow the keeper interfaces and handler code to be defined upfront in proto files. This could simplify what is actually needed to write a module.

[tac0turtle]

this is encapsulated in appearing epic. Closing this issue