Move repository interfaces to Application layer

Refactored IRepository<T> and ICatalogRepository to reside in the DbFirst.Application layer instead of Domain. Updated namespaces, using statements, and all references in services and handlers. Adjusted csproj dependencies to reflect the new structure. Updated comments to clarify Clean Architecture rationale and improved separation of concerns.

DbFirst.Domain/DbFirst.Domain.csproj

@@ -6,4 +6,8 @@
     <Nullable>enable</Nullable>
   </PropertyGroup>
 
+  <ItemGroup>
+    <Folder Include="Repositories\" />
+  </ItemGroup>
+
 </Project>

DbFirst.Domain/Repositories/ICatalogRepository.cs

@@ -1,41 +0,0 @@
-using DbFirst.Domain.Entities;
-
-namespace DbFirst.Domain.Repositories;
-
-// TODO: instead of creating interface per entity, consider using generic repository pattern (eg. IRepository<T>) to reduce code duplication.
-
-/* Copilot's Response:
-
-A generic Repository<T> isn’t really worthwhile here:
-    • Reads from the view are generic, but inserts/updates/deletes go through stored procedures with special parameters/output GUIDs.You’d need lots of exceptions/overrides—little gain.
-    • Operations aren’t symmetric (separate procs for insert/update/delete with output handling and reload), so a one-size-fits-all CRUD pattern doesn’t fit well.
-    • Better to keep the specialized repo.If you want reuse, extract small helpers (e.g., for proc calls/output parameters/reload) instead of forcing a generic repository. */
-
-
-/* Hakan's Response: 
- * I think it still makes sense. An execute SQL method can be added to repository. The relevant SQL can be executed in the application layer.
- * Because the application layer is no longer dependent on a method like CreateAsync. It is now directly dependent on that procedure.
- */
-
-// TODO: move to application layer as a part of clean architecture
-
-/* Copilot's Response:
-
-    • Common: Keep the interface in the Domain layer, implementation in Infrastructure. Domain defines the data access contract, Infrastructure provides the implementation.
-    That matches typical DDD/Clean Architecture.
-    • Alternative: Move the interface to the Application layer. Then only Application depends on Infrastructure, Domain stays isolated from infra contracts.
-    Pro: Domain contains only models/rules.
-    Con: If Domain logic needs repos, it would depend on Application, weakening the layer separation.
-    Recommendation: Keep the interface in Domain. It’s conventional, clean, and avoids a Domain -> Application dependency. Implementation stays in Infrastructure. */
-
-/* Hakan's Response:
- *  I don't think there's any point in keeping repository interfaces in the domain layer. These interfaces will be used in the application layer, not the domain layer. 
- *  Furthermore, this is how they are used in the most popular clean architecture pattern. 
- *  See: https://github.com/jasontaylordev/CleanArchitecture/blob/main/src/Infrastructure/Identity/IdentityService.cs
- */
-
-public interface ICatalogRepository : IRepository<VwmyCatalog>
-{
-    Task<VwmyCatalog?> GetByTitleAsync(string title, CancellationToken cancellationToken = default);
-    Task<VwmyCatalog?> UpdateAsync(int id, VwmyCatalog catalog, CatalogUpdateProcedure procedure, CancellationToken cancellationToken = default);
-}

DbFirst.Domain/Repositories/IRepository.cs

@@ -1,10 +0,0 @@
-namespace DbFirst.Domain.Repositories;
-
-public interface IRepository<T>
-{
-    Task<List<T>> GetAllAsync(CancellationToken cancellationToken = default);
-    Task<T?> GetByIdAsync(int id, CancellationToken cancellationToken = default);
-    Task<T> InsertAsync(T entity, CancellationToken cancellationToken = default);
-    Task<T?> UpdateAsync(int id, T entity, CancellationToken cancellationToken = default);
-    Task<bool> DeleteAsync(int id, CancellationToken cancellationToken = default);
-}