Fine Grained Modularity

[matiwinnetou]

For any of the module being developed it should be possible:

• (1) to disable all controllers, leaving only service layer and repository layer
• (2) removing repository layer leaving only "business events"
• (3) ability to register for business events, e.g. via Spring's Event Bus so that developer can selectively consume data
• (4) spring Modulith support so that those business events can be propagated to other modules and Yaci-Store can be separate

I have cases sometimes where I need 1, 2, 3, 4 and it all depends on a use case where Yaci-Store is being used.

This issue feels a bit wrong, actually this should be probably an ADR (Architecture Decision Record)

[satran004]

Thanks @matiwinnetou . We will create a separate enhancement for each item during implementation.

Regarding pt-2, some of the business events may still require a repository layer, as they might depend on previously processed data. So, we will implement pt-2 wherever possible and provide documentation for it.

pt-3: Is the current way of listening to business events not sufficient? Using @EventListener?

[satran004]

(1) To Disable All Controllers, Leaving Only the Service Layer and Repository Layer

Instead of enabling and disabling controllers in a store through config options, we can explore creating a separate API module for each store. So, we can have a top-level "API" folder (like "stores"), and then for each store module, add a corresponding API module. For example: utxo-api, blocks-api, assets-api, etc.

The existing controllers and DTO classes will be moved to the corresponding API module. Each API module is published as a separate library.

Pros:

• A specific store API library can be added to access controller endpoints. For example, adding utxo-starter and utxo-api dependencies allows access to both the UTXO store and its endpoints.

• This will help us keep the Storage interface lean. The storage interface will only contain methods required to process and store data.

• Different API types can be supported in the future without any impact on the store module.

Cons:

• Additional sub-modules may increase maintenance overhead.
• Additional dependencies in client applications.

[satran004]

https://github.com/bloxbean/yaci-store/issues/130