Update ch01.asciidoc

Fixed typo, asynchrnous -> asynchronous

Author: justin0022

chapters/ch01.asciidoc

@@ -200,7 +200,7 @@ We can apply modular design concepts on every level of a given system. If a proj
 
 When we want to make an application more maintainable, we should consider creating explicitly defined layers of code, so that we can grow each layer horizontally while preventing the complexity of those additions from spreading to other, unrelated, layers. The same thought process can be applied to individual components, splitting them into two or more smaller components that are then tied together by yet another small component, which could act as a composition layer whose sole responsibility is knitting together several underlying components.
 
-At the module level, we should strive to keep functions simple and expressive, with descriptive names and not too many responsibilities. Maybe we'll have a function dedicated exclusively to broidering together a group of tasks under a particular asynchrnous flow, while having other functions for each task that we need to perform within that control flow. The topmost flow controlling function could be exposed as a public interface method for our module, but the only part of it that should be treated as public interface are the parameters that we receive as inputs for that function and the output produced by that same topmost function. Everything else becomes an implementation detail and is, as such, to be considered swappable.
+At the module level, we should strive to keep functions simple and expressive, with descriptive names and not too many responsibilities. Maybe we'll have a function dedicated exclusively to broidering together a group of tasks under a particular asynchronous flow, while having other functions for each task that we need to perform within that control flow. The topmost flow controlling function could be exposed as a public interface method for our module, but the only part of it that should be treated as public interface are the parameters that we receive as inputs for that function and the output produced by that same topmost function. Everything else becomes an implementation detail and is, as such, to be considered swappable.
 
 The internal functions of a module won't have as rigid of an interface either: as long as the public interface holds, we can change the implementation -- including the interfaces of functions that make up that implementation -- however we want. This is not to say, however, that we should treat those interfaces any less deliberately. The key to proper modular design is in having an utmost respect for all interfaces, and that includes the interfaces exposed by internal functions.