The Refactor

[dodo920306]

Let's face it: the current state of this project’s code is not so good.

Contributions over time have lacked consistency, leading to duplicated implementations and a fragmented structure that makes maintenance and development difficult.

The combination of Python, Django, and object-oriented design has introduced unnecessary complexity, and without long-term technical stewardship, the project has become hard to extend.

Another pressing issue is the number of long-standing bugs. For a project that has been in existence for over six years, there remain issues that ideally should have been addressed very early on. Many of these are not superficial problems that tools or automated testing could easily detect, but deeper logical flaws that only become evident when the affected code paths are used.

Additionally, it seems that the project has not fully embraced the design principles of Django REST Framework (DRF). For example, serializers are often used only for traffic handling, while much of the core business logic resides in views.py, which goes against DRF’s intended design practices.

To summary, a refactor is inevitable, and to make sure I’m not just another person who criticizes without acting, I’ll do it myself.

[dodo920306]

@yeasy Here is the latest update. I've reintroduced the agents as discussed, and all Hyperledger Fabric operations have now been consolidated within them.

This change inevitably increased the scope of the PR. Ideally, some of this restructuring could have been split into a follow-up PR, but given the current context, I've consolidated everything here to keep the refactor coherent.

At this stage, I believe the branch is in a mergeable state. While there is still room for improvement, those refinements can be addressed incrementally in subsequent PRs.

Since this branch is already significantly ahead of main (118 commits), I think it would be healthier for the project to bring main up to date with the refactor, rather than continuing to extend a long-running branch. Keeping branches aligned will make future development and review cycles much smoother.

If reviewing the full diff is challenging due to its size, I suggest focusing on the resulting architecture and overall behavior. I'm of course happy to clarify any specific concerns.

Given the above, I've updated the target branch to main. If you feel there's a strong reason to follow a different merge strategy, I'm open to discussing it.

Overall, I believe this PR is ready to move forward.

[yeasy]

It will be better to have stable code before merging into main.
We need more test cases. can you help enhance the testing?

[dodo920306]

It will be better to have stable code before merging into main. We need more test cases. can you help enhance the testing?

I can try, but I’d like to point out that doing so within this PR will further increase its scope and complexity.

[yeasy]

Another approach is that checkout a new v1-stable branch and merge your refactor into main.
How do you think?
@dodo920306

[dodo920306]

Another approach is that checkout a new v1-stable branch and merge your refactor into main. How do you think? @dodo920306

That's actaully a good idea! We can check out a release/1.2 branch from f9d56cf (tag v1.2.0).

[yeasy]

Another approach is that checkout a new v1-stable branch and merge your refactor into main. How do you think? @dodo920306

That's actaully a good idea! We can check out a release/1.2 branch from f9d56cf (tag v1.2.0).

@YoungHypo how do you think?

[YoungHypo]

Another approach is that checkout a new v1-stable branch and merge your refactor into main. How do you think? @dodo920306

That's actaully a good idea! We can check out a release/1.2 branch from f9d56cf (tag v1.2.0).

@YoungHypo how do you think?

LGTM.

[dodo920306]

@yeasy Here is a public demo video for this PR (with English subtitles).
https://youtu.be/4RJQRKVo9CQ