Update 2024-09-29-modules.md

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

@@ -15,7 +15,7 @@ One of the most common things we interact with outside of our projects are web s
 </p>
 
 #### Interfaces
-A common pattern is the usage of a style of class called an interface. It allows us to easily define what exact behavior of a class is, without referencing the class itself. This can be useful for cases where we want to abstract out the implementation from the consumer of the class, or if we want to be able to switch out the implementation itself without impacting the consumer. Lots of good reasons to use an interface exist, but we can also simplify it down to something like this:
+A common pattern is the usage of a style of class called an interface. It allows us to easily define what the expected behavior is without referencing the class itself. This can be useful for cases where we want to abstract out the implementation from the consumer of the class, or if we want to be able to switch out the implementation itself without impacting the consumer. Lots of good reasons to use an interface exist, but we can also simplify it down to something like this:
 <p align="center" style="padding-top:20px;padding-bottom:20px;">
   <img src="/assets/images/modules/interfaces.png" width="100%" />
 </p>
@@ -28,7 +28,7 @@ The examples shown above highlight a commonality seen across domains. Using an a
 </p>
 
 #### Build cache
-The ramifications to breaking up your code like this, is that only your contracts are references by consuming code. This allows the build cache to only need to rebuild what has been changed. For example if you adjusted an implementation of a given unit, the callers wouldn't need to be rebuilt. They only accessed it via the interface so nothing changed for them.
+The ramification to breaking up your code like this is that only your contracts are referenced by consuming code. This allows the build cache to only need to rebuild what has been changed. For example if you adjusted an implementation of a given unit, the callers wouldn't need to be rebuilt. They only accessed it via the interface so nothing changed for them.
 #### Maintainability
 Since we are now enforcing the access of business logic via contract it makes it much harder to intermingle across boundaries, since they are strictly defined. You can always change or extend them as needed but it is a very intention change. If your team is big enough those contracts could even have different code owners who might have an opinion on changing the contract.
 #### Scaled out