Feat: Change the project structure to a clean one

[logicalangel]

Dears, I think the project structure should change to a clear and union-based one. I suggest the Hexagonal architecture: https://medium.com/@matiasvarela/hexagonal-architecture-in-go-cfd4e436faa3

with the structure that is explained in this repository: https://github.com/evrone/go-clean-template

The benefits of using union-based architecture are:

• Separating the logic of our application from outer dependencies
• Making the codes easier to understand
• Decoupling each layer and preventing rewriting in situations when we want to change one of our external dependency
• Making our application tastable, with the ability to mock other layers

In this change, I want to reorganize the project which is the first step to making the project clear. A desired view of the app after change:

• cmd: Broker, Consumers, Worker
• config
• pkg:
• • utils
• • • message pack encoding
• • • ...
• Internal:
• • model
• • transport
• • • WebSocket
• • • Blockchain Clients
• • • Databases
• • • ...
• • service
• • • Prof of stake
• • • ...

[pouya-eghbali]

@logicalangel is this a task multiple people can work on? We need to plan this ahead before we jump into the implementation.

[logicalangel]

@logicalangel is this a task multiple people can work on? We need to plan this ahead before we jump into the implementation.

It can be multistep, I think we should start changing from each layer.

• First of all, we should add Dependency Injection with this pattern:

  type ourConcern struct {
  ... all layer dependacies
  }
  func (o *ourConcern) RelatedFunction(){}
  func New(... pass dependacies ) *ourConcern {
  return &ourConcern { ... set dependacies }
  }

  and all layers should transform into this shape. So we can have multiple tasks for each layer.

• We should use interfaces instead of referring directly. If we use interfaces in each layer contractor, it helps us to capsulate internal asserts and be pluggable about outer dependencies. So defining the interface for each dependency can be separated tasks.

• Extracting use cases from socket handlers is necessary. our business logic should not depend on the type of triggers or even on a specific framework.

• all configs should aggregate in one place. it makes our code simpler. I think this task can be huge. So it's better to split it into multiple tasks.

[logicalangel]

Solved in several previous PRs.