Typos

docs/learnings/2024-09-29-modules.md

@@ -22,7 +22,7 @@ A common pattern is the usage of a style of class called an interface. It allows
 
 ## Modules
 #### Standing on the shoulders of giants
-The examples shown above highlight a commonality seen across domains. Using an abstraction, we are able to scope behavior and easily maintain our business logic. This can be adapted to our own problem. If we break up our code such that we define a single unit into both a contract and an implementation, it can be accessed without needing to pulling in the whole implementation.
+The examples shown above highlight a commonality seen across domains. Using an abstraction, we are able to scope behavior and easily maintain our business logic. This can be adapted to our own problem. If we break up our code such that we define a single unit into both a contract module and an implementation module, it can be accessed without needing to pulling in the whole implementation.
 <p align="center" style="padding-top:20px;padding-bottom:20px;">
   <img src="/assets/images/modules/simple.png" width="100%" />
 </p>
@@ -38,7 +38,7 @@ You won't be able to avoid the spiderweb that will become your module dependency
 </p>
 
 #### Implementation details
-Contract modules can comprise of interfaces, data classes, enum/sealed classes, and constants. Implementations can be bound to the implementations via dependency injection, preferably using Hilt. You can even abstract away entire experiences behind a contract and simply launch them via interface. Edge cases like reusable views should probably be standalone modules only used by implementations, but keep it tightly scoped or it quickly can get out of hand.
+Contract modules can comprise of interfaces, data classes, enum/sealed classes, and constants. Implementations can be bound to the contracts via dependency injection, preferably using Hilt. You can even abstract away entire experiences behind a contract and simply launch them via interface. Edge cases like reusable views should probably be standalone modules only used by implementations, but keep it tightly scoped or it quickly can get out of hand.
 #### References
 - [Solid Modularization - Untangling the dependency graph](https://www.droidcon.com/2022/06/28/solid-modularization-untangling-the-dependency-graph/)
 - [Android at Scale (with Circuit)](https://www.johnbuhanan.dev/android-at-scale-with-circuit/)