Refactor CORS config; add architectural commentary

Refactored CORS setup to be environment-aware, restricting origins in production and relaxing in development. Added extensive comments and discussion on service and repository layer design, including clean architecture best practices and CQRS/MediatR considerations. No changes to business logic; documentation and intent clarified for maintainers.

DbFirst.Application/Catalogs/CatalogService.cs

@@ -21,7 +21,17 @@ Cons/Practical here:
 Conclusion: For this solution a generic service would be more overhead than benefit. If you later have multiple very similar entities without special logic,
 you could consider a lightweight generic interface/base; for now, the specialized service implementation is cleaner. */
 
+/* Hakan's Response: 
+ * No, it absolutely makes sense to create a generic service using Options pattern. So, you can easily inject your SQL queries or stored procedure names via configuration.
+ * see: https://docs.microsoft.com/en-us/dotnet/core/extensions/options
+ */
+
 //TODO: implement CQRS pattern with MediatR
+
+/* Hakan's response
+ * Here is the main part. We dont even need a service layer if we implement CQRS with MediatR at least for CRUD operations.
+ */
+
 public class CatalogService : ICatalogService
 {
     private readonly ICatalogRepository _repository;