-
Notifications
You must be signed in to change notification settings - Fork 40
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
Add Reserved
contract
#110
Comments
Thanks for the suggestion and sorry for the delay, I've been on holiday. It's an interesting idea. Is something like this what you are envisaging?
AlternativesIt's worth exploring design alternatives, do you have any thoughts on these? Forbidden + ignored importAn alternative approach would be to use a
Pro: It already works. Verbose forbidden
Pro: It already works. Closed layersA common architectural pattern that isn't supported yet is closed layers. Maybe we could add an option to the layers contract like so, and treat the reserved module as a lower-level layer.
Pro: fits well with an existing architectural pattern, and is a feature that I'd like to add at some point anyway. ProtectedThis is the same as the reserved idea but with different language.
Pro: simple, flexible, IMO easier to understand than the 'reserved' concept. |
Yeah, |
I agree, I think the Protected contract would be the best way forward. Happy to consider a PR at some point - in the meantime you can always make a custom contract to do this. |
I think there could be one more very generic contract type - reserved contract. It would be basically a mirror reflection of
forbidden
contract. Basic configuration could look like this:This contract would fail if any of
reserved_modules
are imported OUTSIDE ofallowed_modules
. This would be very helpful to enforce DDD or ports and adapters approach, when you want to prevent leaking implementation details bound to specific third-party library/API to rest of the app.PS - great library, congratulations!
The text was updated successfully, but these errors were encountered: