Improved architecture for submodule wiring #1196
Labels
Scope: x/ecocredit
Issues that update the x/ecocredit module
Type: Refactor
A code change that neither fixes a bug nor adds a feature
Summary
When implementing basket and marketplace functionality, we went with a submodule architecture. There are a lot of open questions remaining on how this architecture should look. Opening this issue to discuss improvements.
We currently have directories for each submodule within the root-level ecocredit module directory but each subdirectory only includes the generate types, the stateless message implementation, and stateless utility functions. The server/keeper and client implementation for each submodule is nested within submodule subdirectories within the root-level client and server directories but could be nested within the directories for each submodule within the root-level ecocredit module directory.
Should client and server/keeper directories for each submodule be nested within the root-level submodule directory? Do we plan on supporting multiple proto package versions for each submodule and, if so, how would this look? How will this submodule architecture work with cosmos-sdk v1? What improvements can we make to the submodule architecture approach?
Problem Definition
There is a lack of clarity on what submodule architecture should look like.
Proposal
[ work in progress ]
For Admin Use
The text was updated successfully, but these errors were encountered: