diff --git a/DbFirst.Domain/Repositories/ICatalogRepository.cs b/DbFirst.Domain/Repositories/ICatalogRepository.cs
index 020353f..bd50be8 100644
--- a/DbFirst.Domain/Repositories/ICatalogRepository.cs
+++ b/DbFirst.Domain/Repositories/ICatalogRepository.cs
@@ -1,4 +1,4 @@
-using DbFirst.Domain.Entities;
+using DbFirst.Domain.Entities;
 
 namespace DbFirst.Domain.Repositories;
 
@@ -6,12 +6,22 @@ namespace DbFirst.Domain.Repositories;
 
 /* 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. */
+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. */
 
 // 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. */
+
 public interface ICatalogRepository
 {
     Task<List<VwmyCatalog>> GetAllAsync(CancellationToken cancellationToken = default);