@blackcode_sa/metaestetics-api 1.13.4 → 1.13.5

package/src/services/README.md

@@ -1,106 +1,106 @@
-# Services
-
-This directory contains service modules that implement the business logic of the application. Services act as an intermediary layer between the API handlers and data models, encapsulating complex operations and enforcing business rules.
-
-## Service Responsibilities
-
-Services handle:
-
-1. **Business Logic**: Implementing complex business rules and workflows
-2. **Data Validation**: Ensuring data integrity before persistence
-3. **Transaction Management**: Handling atomic operations across multiple entities
-4. **Error Handling**: Providing consistent error responses for business logic failures
-5. **Integration**: Coordinating interactions with external services and APIs
-
-## Service Structure
-
-Each service typically follows this pattern:
-
-```typescript
-// Service function signature
-export const someServiceFunction = async (
-  params: SomeParamsType,
-  options?: SomeOptionsType
-): Promise<SomeReturnType> => {
-  try {
-    // 1. Input validation
-    const validatedData = someSchema.parse(params);
-
-    // 2. Business logic implementation
-    // ...
-
-    // 3. Data persistence
-    const result = await saveToDatabase(processedData);
-
-    // 4. Return formatted response
-    return result;
-  } catch (error) {
-    // Error handling and transformation
-    if (error instanceof z.ZodError) {
-      throw new ValidationError("Invalid input data", error);
-    }
-    // Other error handling...
-    throw error;
-  }
-};
-```
-
-## Core Services
-
-The application includes the following service modules:
-
-- **auth**: User authentication and authorization
-- **user**: User profile management
-- **practitioner**: Practitioner profile and availability management
-- **clinic**: Clinic/facility management
-- **procedure**: Medical procedure and service management
-- **appointment**: Appointment scheduling and management
-- **review**: Practitioner review and rating
-- **search**: Search functionality across entities
-- **notification**: User notification delivery
-- **file**: File upload and management
-
-## Error Handling
-
-Services use a consistent error handling approach:
-
-- Custom error types for different failure scenarios
-- Error transformation to provide meaningful context
-- Detailed error information for debugging while maintaining security
-
-## Transaction Management
-
-For operations affecting multiple entities, services implement transaction patterns to ensure data consistency:
-
-```typescript
-// Example transaction pattern
-export const complexOperation = async (data: SomeType): Promise<ResultType> => {
-  // Begin transaction context
-  try {
-    // Multiple database operations...
-
-    // If all succeed, return result
-    return result;
-  } catch (error) {
-    // Handle error and ensure rollback if needed
-    throw error;
-  }
-};
-```
-
-## Service Dependencies
-
-Services may depend on other services to complete their operations. Dependencies are typically:
-
-- Explicitly imported at the module level
-- Passed as parameters to functions when needed for testing
-- Designed to avoid circular dependencies
-
-## Testing
-
-Services are designed to be easily testable:
-
-- Pure functions where possible
-- External dependencies injectable for mocking
-- Clear input/output contracts
-- Isolated business logic
+# Services
+
+This directory contains service modules that implement the business logic of the application. Services act as an intermediary layer between the API handlers and data models, encapsulating complex operations and enforcing business rules.
+
+## Service Responsibilities
+
+Services handle:
+
+1. **Business Logic**: Implementing complex business rules and workflows
+2. **Data Validation**: Ensuring data integrity before persistence
+3. **Transaction Management**: Handling atomic operations across multiple entities
+4. **Error Handling**: Providing consistent error responses for business logic failures
+5. **Integration**: Coordinating interactions with external services and APIs
+
+## Service Structure
+
+Each service typically follows this pattern:
+
+```typescript
+// Service function signature
+export const someServiceFunction = async (
+  params: SomeParamsType,
+  options?: SomeOptionsType
+): Promise<SomeReturnType> => {
+  try {
+    // 1. Input validation
+    const validatedData = someSchema.parse(params);
+
+    // 2. Business logic implementation
+    // ...
+
+    // 3. Data persistence
+    const result = await saveToDatabase(processedData);
+
+    // 4. Return formatted response
+    return result;
+  } catch (error) {
+    // Error handling and transformation
+    if (error instanceof z.ZodError) {
+      throw new ValidationError("Invalid input data", error);
+    }
+    // Other error handling...
+    throw error;
+  }
+};
+```
+
+## Core Services
+
+The application includes the following service modules:
+
+- **auth**: User authentication and authorization
+- **user**: User profile management
+- **practitioner**: Practitioner profile and availability management
+- **clinic**: Clinic/facility management
+- **procedure**: Medical procedure and service management
+- **appointment**: Appointment scheduling and management
+- **review**: Practitioner review and rating
+- **search**: Search functionality across entities
+- **notification**: User notification delivery
+- **file**: File upload and management
+
+## Error Handling
+
+Services use a consistent error handling approach:
+
+- Custom error types for different failure scenarios
+- Error transformation to provide meaningful context
+- Detailed error information for debugging while maintaining security
+
+## Transaction Management
+
+For operations affecting multiple entities, services implement transaction patterns to ensure data consistency:
+
+```typescript
+// Example transaction pattern
+export const complexOperation = async (data: SomeType): Promise<ResultType> => {
+  // Begin transaction context
+  try {
+    // Multiple database operations...
+
+    // If all succeed, return result
+    return result;
+  } catch (error) {
+    // Handle error and ensure rollback if needed
+    throw error;
+  }
+};
+```
+
+## Service Dependencies
+
+Services may depend on other services to complete their operations. Dependencies are typically:
+
+- Explicitly imported at the module level
+- Passed as parameters to functions when needed for testing
+- Designed to avoid circular dependencies
+
+## Testing
+
+Services are designed to be easily testable:
+
+- Pure functions where possible
+- External dependencies injectable for mocking
+- Clear input/output contracts
+- Isolated business logic

package/src/services/__tests__/auth/auth.mock.test.ts

@@ -1,17 +1,17 @@
-import { setupMocks, mockFirebaseUser } from "./auth.setup";
-
-describe("Firebase Mock Setup", () => {
-  beforeEach(() => {
-    setupMocks();
-  });
-
-  it("should properly initialize mock Firebase instance", async () => {
-    const { getFirebaseInstance } = require("../../../config/firebase");
-    const instance = await getFirebaseInstance();
-
-    expect(instance).toBeDefined();
-    expect(instance.db).toBeDefined();
-    expect(instance.auth).toBeDefined();
-    expect(instance.auth.currentUser).toEqual(mockFirebaseUser);
-  });
-});
+import { setupMocks, mockFirebaseUser } from "./auth.setup";
+
+describe("Firebase Mock Setup", () => {
+  beforeEach(() => {
+    setupMocks();
+  });
+
+  it("should properly initialize mock Firebase instance", async () => {
+    const { getFirebaseInstance } = require("../../../config/firebase");
+    const instance = await getFirebaseInstance();
+
+    expect(instance).toBeDefined();
+    expect(instance.db).toBeDefined();
+    expect(instance.auth).toBeDefined();
+    expect(instance.auth.currentUser).toEqual(mockFirebaseUser);
+  });
+});