diff --git a/README.md b/README.md index 602b12ace49cfe5e4314809eded85458f074b0a4..47928623960a8833a60ba03f1429448b96cad626 100644 --- a/README.md +++ b/README.md @@ -84,5 +84,10 @@ When considering the uniqueness of elements like the id in Program or the url in Rust’s strict safety guarantees push us to consider thread-safe data handling at every turn. In our implementation, we opted for DashMap to maintain a global list of subscribers because it inherently manages synchronization across threads. While one could consider implementing a Singleton pattern with a plain HashMap to provide a single shared instance, that approach would force us to add our own synchronization layers (using Mutex or RwLock), complicating the design. DashMap simplifies this by offering built-in, concurrent-safe operations, making it a more straightforward solution in a multithreaded environment. #### Reflection Publisher-2 +In an MVC compound pattern, the Model often takes on both data storage and business logic roles, but separating out the Service and Repository components is essential from a design principles standpoint. This separation follows the Single Responsibility Principle, which states that each component should only have one reason to change. By isolating the business logic in a Service and the data access in a Repository, we ensure that each part of the system remains focused, easier to test, and more adaptable to future changes. This clear division not only simplifies maintenance but also makes the code more modular, allowing us to improve or replace one part without affecting the others. + +If we were to use only the Model for handling both business logic and data persistence, the interactions between different entities—like Program, Subscriber, and Notification—would become tangled. Each model would need to manage its own data operations and logic, leading to duplicated code and tightly coupled components. This would quickly escalate the code complexity, making it hard to track how changes in one model affect the others. In such a scenario, any update in business logic might inadvertently impact data access routines, increasing the risk of bugs and making the system more difficult to maintain or scale. + +I have also explored Postman as a tool to test my current work, and I found it incredibly useful. Postman allows me to quickly send API requests and verify responses, which is essential for ensuring that endpoints function correctly. I appreciate features such as automated testing scripts, environment management for easily switching between development and production settings, and the ability to organize requests into collections. These features not only streamline the testing process for my individual projects but also provide valuable documentation that can be shared with my group members, improving collaboration and overall project quality. #### Reflection Publisher-3