Decouple from Third Parties edit #35
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ntache-81
commented
Feb 11, 2025
| Choose am important dependency and refactor your code to introduce abstractions such as interfaces or abstract classes to encapsulate interactions with that dependency. | ||
| Rewrite the implementations to depend on these abstractions rather than the concrete third-party tools. | ||
| Choose an important dependency and refactor your code to introduce abstractions (such as interfaces or abstract classes) to encapsulate interactions with that dependency. | ||
| Rewrite the implementations to depend on these abstractions, rather than the concrete third-party tools. |
Collaborator
Author
There was a problem hiding this comment.
I’m not sure I understand. Are we saying rather than using third-party tools, have your team rewrite the implementations…? Or are we saying Have your team rewrite the implementations to depend on these abstractions, rather than depend on the third-party tools?
ntache-81
commented
Feb 11, 2025
| ### [Lead a Workshop](/practices/lead-workshops.md) | ||
|
|
||
| Start by identifying the dependencies your project currently has on third-party software, frameworks, or libraries. Make a list of these dependencies and assess how tightly coupled they are to your codebase. | ||
| Start by identifying the dependencies your project currently has on third-party software, frameworks, or libraries. Make a list of these dependencies and then assess how tightly coupled they are to your codebase. |
Collaborator
Author
There was a problem hiding this comment.
Then what? Suggest fleshing this out a bit more. What are the actionable takeaways, once the assessment is done? For those tools the team agrees are tighly coupled to the codebase, brainstorm ways to gradually reduce coupling where possible?
ntache-81
commented
Feb 11, 2025
| The article delves into various architectural methodologies such as Hexagonal Architecture, Onion Architecture, Screaming Architecture, DCI, and BCE, with a focus on principles like framework independence, testability, and concern separation. | ||
| It introduces "The Clean Architecture," centered on the Dependency Rule, depicted by concentric circles signifying different software domains and their corresponding responsibilities. | ||
| Adhering to the Dependency Rule promotes high cohesion and low coupling. When managing dependencies with third parties, Clean Architecture provides a structured approach by encapsulating external dependencies within outer layers, effectively isolating them from core business logic. | ||
| This article explores architectures that focus on framework independence, testability, and concern separation (such as Hexagonal Architecture, Onion Architecture, Screaming Architecture, DCI, and BCE). |
Collaborator
Author
There was a problem hiding this comment.
I cut this down for concision/simplicity. Please review carefully to ensure it’s all accurate.
ntache-81
commented
Feb 11, 2025
| ### [Code Maintainability](capabilities/tech/code-maintainability.md) | ||
|
|
||
| The Decouple from Third Parties practice significantly supports the Code Maintainability capability by advocating for the minimization of dependencies on third-party software, thereby ensuring that code remains adaptable and easy to maintain over time. By abstracting dependencies behind interfaces and relying on abstractions like interfaces instead of specific third-party tools, teams can enhance the portability of their code, facilitate comprehensive testing through the creation of mock or stub implementations, and enable flexibility in migration to alternative solutions if necessary. | ||
| The Decouple from Third Parties practice significantly supports the Code Maintainability capability by advocating for minimized dependency on third-party software. Minimizing dependencies ensures that code remains adaptable and easy to maintain over time. By abstracting dependencies behind interfaces and relying on abstractions like interfaces instead of third-party tools, teams can enhance the portability of their code and enable flexibility in migration to alternative solutions if necessary. |
Collaborator
Author
There was a problem hiding this comment.
Re: the sentence that reads "By abstracting dependencies behind interfaces and relying on abstractions like interfaces instead of third-party tools..."
- Are we sort of saying the same thing twice? Edit to “By relying on abstractions like interfaces instead of third-party tools…”?
Collaborator
Author
|
I notice "Use Test Doubles" in the master list of planned pratices. Add this practice to Gaining Traction section here, since test doubles are referenced many times? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Edit to Decouple from Third Parties practice.