Making Besu more modular requires thinking about the dimensions along which those modules are divided up and separated from each other. Those separations can be categorized into two types: areas of related business logic, and areas of related software function. The former is the domain of "stuff Ethereum needs" and the later is the domain of "stuff good Java software needs". When we modularize Besu, we are looking to produce reusable, composable software components within the business logic domain.
Bounded Contexts / Business Logic / Blockchain Domain are all synonyms for the type of modules we want to create to serve the pillars of our 2022 Vision. We will know we are doing this right when users can easily create a Besu that combines different modules into the client they need.
Cross Cutting Concerns are a little bit different. These should be invisible to the users, but very helpful to the developers. Any Bounded Context may depend on any mix of Cross Cutting Concerns. This part is ok to be a web of dependencies, they are often external projects/libaries we have selected for use all throughout Besu.
| Business Logic | Cross Cutting Concerns |
|---|---|
|
|
Proof of Concept:
Introduce Dagger to implement a vertical slice of functionality. We need to find a feature that touches on a few cross-cutting concerns, but just one Bounded Context.
Nominees:
- Jumpdest caching. Only relevant to the EVM, but requires caching, configuration, Observability, and hashing. Plan would be to provide each of these as a dependency.
- PoA consensus mechanisms. Impact TBD.
- Transaction pool. Impact TBD.
- Merge Context. What if the Merge Coordinator and related classes could be a dagger module?
- Protocol Schedule. Impact TBD.
Once the question of "will daggers dependency injection make for cleaner composition of modules into an application" is answered, we can then start to incrementally adopt it within each bounded context, and across the cross-cutting concerns.