feat: update module docs

Author: jeastham1993

docs/docs/module6/2_rust_modules.md

@@ -28,7 +28,7 @@ mod core; // Tells Rust to look for core.rs or core/mod.rs
 The second approach is more common for larger applications and is what you'll use in this module.
 
 :::info
-When you declare a `mod core` the compiler is going to look for a file called `core.rs` **OR** `core/mod.rs`
+When you declare a `mod core` the compiler is going to look for a file called `core.rs` **OR** `core/mod.rs`. If you have a relatively simple module, using a single file is great. As the code in your module starts to grow though, it might be more beneficial to move that to a folder then split the single file down into independent files
 :::
 
 ### Module Visibility
@@ -40,6 +40,7 @@ Everything is private to the current file as a default in Rust
 :::
 
 - No modifier: Private to the current module
+- `no identifier`: Private within the current file
 - `pub`: Public, visible everywhere
 - `pub(crate)`: Visible only within the current crate
 - `pub(super)`: Visible to the parent module

docs/docs/module6/4_challenge.md

@@ -7,9 +7,9 @@ sidebar_position: 4
 Now it's time to apply what you've learned about modular architecture! In this module's challenge, you'll:
 
 1. Take the monolithic web API from the previous module and split it into a modular architecture
-2. Create separate files for:
-   - `core.rs`: Containing your domain models and business logic
-   - `data_access.rs`: Containing your data storage mechanism
+2. Create separate modules for:
+   - `core`: Containing your domain models and business logic, this should use the folder (`core`) method for defining a module
+   - `data_access.rs`: Containing your data storage mechanism, this should use the single file method for defining a module
    - `main.rs`: For your API endpoints and application setup
 3. Apply appropriate visibility modifiers to enforce architectural boundaries
 4. Ensure all modules are properly connected and the API still works as expected