[FEATURE] Migrate to target arch
yurvon-screamo opened this issue · 2 comments
Why do we need this improvement?
- Ensuring the possibility of development
- Simplifying the support process
How will this change help?
The adoption of an architectural decision will determine the possible vector of development for the near (or long) time
Screenshots
How could it be implemented/designed?
The current architecture proposal is shown in the picture.
The main ideas:
- separating the implementation of document generation from the delivery of the document in the right form to the right place
- relying on schema from the LEGO library
- maintaining the ability to migrate (ideally seamlessly) users from an existing version
- full openness to new ways of generating documents (both within the framework of our new functionality and within the framework of implementation at the user application level)
- full openness to new scenarios for using the generated document (both within the framework of our new functionality and within the framework of implementation at the user application level)
I did not aim to reflect the architecture of the current implementation.
On the contrary, the main purpose of this is to turn the library into some kind of platform, open both to implement new ways of converting code into asyncapi document, and to further obtain this document in the desired form.
Please note that this issue does not address the issue of nuget package delivery. Here we will not define a possible list of them or anything else. (However, I believe that adopting such an architecture will greatly simplify this process in the future)
🚧 Breaking changes
Yes
👀 Have you checked for similar open issues?
- I checked and didn't find a similar issue
🏢 Have you read the Contributing Guidelines?
- I have read the Contributing Guidelines
Are you willing to work on this issue?
Yes I am willing to submit a PR!
I'm waiting for comments from the community and starting to implement