Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Improvement] Move serialization and deserialization process of configuration out of the scope of core domain #3306

Closed
HHobeck opened this issue Dec 9, 2022 · 6 comments

Comments

@HHobeck
Copy link
Contributor

HHobeck commented Dec 9, 2022

Is your improvement request related to a problem? Please describe.
In the discussion of pull-request #3235 (Create new fallback and unknown section in GitVersionConfiguration) we came to the conclusion that it might be a good idea to move the serialization and deserialization process out of the scope of the core domain (see #3235 (comment)).

Detailed Description

The core domain should have only the business logic without the dependency to the Yaml library.

Possible Implementation

Move the logic in GitVersionContextFactory from core to another place and only provide the final GitVersionConfiguration instance to the core domain. The idea is to either make the GitVersionConfiguration immutable or provide the entity via interface or abstract class.

@HHobeck HHobeck added this to the 6.x milestone Feb 8, 2023
@arturcic
Copy link
Member

I was thinking we need to move Configuration related code into a separate module similarly I did for BuildAgents and Output, I just wonder what should we keep in your opinion in the GitVersion.Core?

The idea is to keep in the GitVersion.Core mainly the interfaces, and the classes related to version calculation.

What do you think?

@HHobeck
Copy link
Contributor Author

HHobeck commented Feb 28, 2023

I was thinking we need to move Configuration related code into a separate module similarly I did for BuildAgents and Output, I just wonder what should we keep in your opinion in the GitVersion.Core?

The idea is to keep in the GitVersion.Core mainly the interfaces, and the classes related to version calculation.

What do you think?

I'm not sure what exactly the target architecture might be: Maybe onion architecture or 3-layer architecture with dedicated business entities. Independent of that the plan is to have some where a place (GitVersion.Core?) with business logic of GitVersion with no dependencies to other services or infrastructure like de-/serialization components. Thus this classes and interfaces which giving the additional value to GitVersion (without dependencies) needs to be present in GitVersion.Core.

@HHobeck
Copy link
Contributor Author

HHobeck commented Feb 28, 2023

Maybe we need to create a concept and write a component diagram to illustrate the dependencies first? @asbjornu: What do you think?

@arturcic
Copy link
Member

arturcic commented Feb 28, 2023

@HHobeck @asbjornu - please check this one #3407 for a first component diagram I have in mind

@arturcic
Copy link
Member

I think I covered this in #3790

@arturcic arturcic modified the milestones: 6.x, 6.0.0-beta.4 Dec 12, 2023
@arturcic
Copy link
Member

🎉 This issue has been resolved in version 6.0.0-beta.4 🎉
The release is available on:

Your GitReleaseManager bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants