Skip to content

6.3 Application (Commands, Queries, Endpoints)

Sprint: Sprint 06 - Customer Domain
Feature ID: 6.3
Subtasks: 6.3.1, 6.3.2, 6.3.3, 6.3.4, 6.3.5, 6.3.6

Objective

Deliver "Application (Commands, Queries, Endpoints)" within Sprint 06 - Customer Domain.

Dependencies

Aggregated from the subtasks below (prerequisite task IDs and enablers):

  • 6.2.2
  • 6.2.3
  • 6.2.4
  • 6.3.1
  • Sprint 01 (object storage)
  • 6.3.4
  • 5.5.1
  • 5.6.1

Subtasks

6.3.1 Register customer command and endpoint

  • ID: 6.3.1
  • Title: Implement RegisterCustomerCommand and POST /api/v1/customers
  • Description: RegisterCustomerCommand (validated, TCKN-checked) creating a PENDING customer, publishing customer.registered.v1 via the outbox. RegisterCustomerRequest / CustomerResponse DTOs; controller returns ApiResult<CustomerResponse> (201).
  • Business Purpose: Customer onboarding entry point (FR-01).
  • Inputs: FR-01, event-catalog customer.registered.v1.
  • Outputs: Command, handler, DTOs, endpoint, outbox publish.
  • Acceptance Criteria:
  • Valid registration returns 201 with a PENDING customer and writes customer.registered.v1; invalid TCKN returns 400.
  • Dependencies: 6.2.2, 6.2.3, 6.2.4
  • Complexity: M

6.3.2 Get and update customer

  • ID: 6.3.2
  • Title: Implement GET and PUT /api/v1/customers/{id}
  • Description: GetCustomerQuery and UpdateCustomerCommand (contact/profile fields). Update publishes customer.updated.v1. Responses mask PII.
  • Business Purpose: View and maintain customer profile (FR-03).
  • Inputs: FR-03, event-catalog customer.updated.v1.
  • Outputs: Query/command, DTOs, endpoints.
  • Acceptance Criteria:
  • GET returns the (PII-masked) customer; PUT updates allowed fields and emits customer.updated.v1; unknown id returns 404.
  • Dependencies: 6.3.1
  • Complexity: M

6.3.3 Address management

  • ID: 6.3.3
  • Title: Implement address add/update/list with default handling
  • Description: Commands/queries and endpoints to add, update, list, and set-default addresses under /api/v1/customers/{id}/addresses; exactly one default enforced (FR-03).
  • Business Purpose: Customer address management (FR-03).
  • Inputs: FR-03, analysis Section 8.1.
  • Outputs: Address commands/queries + endpoints.
  • Acceptance Criteria:
  • Adding a second default unsets the previous; listing returns all addresses with one default.
  • Dependencies: 6.2.4
  • Complexity: M

6.3.4 Document upload (KYC)

  • ID: 6.3.4
  • Title: Implement POST /api/v1/customers/{id}/documents
  • Description: Accept a KYC document (ID_CARD/PASSPORT), store the binary in MinIO (local FS only as a dev fallback) and the object reference in documents, returning the document metadata; downloads are served via time-limited pre-signed URLs (ADR-006). Validate content type/size (FR-03).
  • Business Purpose: Capture KYC evidence (FR-03, AC-01 step 2).
  • Inputs: FR-03, analysis Section 7.1 (MinIO), AC-01.
  • Outputs: Upload command, storage adapter, endpoint.
  • Acceptance Criteria:
  • Uploading a document stores the file, records a documents row with file_ref, and returns metadata; oversized/invalid types are rejected with 400.
  • Dependencies: 6.2.4, Sprint 01 (object storage)
  • Complexity: M

6.3.5 KYC approval/rejection

  • ID: 6.3.5
  • Title: Implement POST /api/v1/customers/{id}/kyc/approve and reject
  • Description: Admin-guarded commands transitioning the customer to ACTIVE (approve) or REJECTED (reject), verifying documents, and publishing customer.kyc-approved.v1 / customer.kyc-rejected.v1 via the outbox; writes an audit row (FR-02, NFR-12).
  • Business Purpose: Complete the KYC decision step (FR-02, AC-01 step 3).
  • Inputs: FR-02, event-catalog kyc events, AC-01.
  • Outputs: Approve/reject commands, endpoints, events, audit.
  • Acceptance Criteria:
  • Approve transitions PENDING->ACTIVE and emits customer.kyc-approved.v1; reject transitions to REJECTED and emits customer.kyc-rejected.v1; both require an admin role and write audit rows.
  • Dependencies: 6.3.4, 5.5.1, 5.6.1
  • Complexity: M

6.3.6 Soft-delete endpoint

  • ID: 6.3.6
  • Title: Implement DELETE /api/v1/customers/{id} (soft-delete)
  • Description: DeleteCustomerCommand setting deleted_at; subsequent reads return 404; writes an audit row (FR-04).
  • Business Purpose: KVKK/GDPR right-to-erasure via soft-delete (FR-04).
  • Inputs: FR-04.
  • Outputs: Delete command + endpoint.
  • Acceptance Criteria:
  • DELETE soft-deletes the customer (row retained, deleted_at set); a later GET returns 404; an audit row is written.
  • Dependencies: 6.2.4, 5.6.1
  • Complexity: S

Acceptance Criteria

Each subtask above carries its own objective, testable acceptance criteria. This feature is complete when every subtask's acceptance criteria are met.

Deliverables

  • Command, handler, DTOs, endpoint, outbox publish.
  • Query/command, DTOs, endpoints.
  • Address commands/queries + endpoints.
  • Upload command, storage adapter, endpoint.
  • Approve/reject commands, endpoints, events, audit.
  • Delete command + endpoint.

Definition of Done

  • All subtasks (6.3.1, 6.3.2, 6.3.3, 6.3.4, 6.3.5, 6.3.6) completed and their acceptance criteria verified.
  • All listed dependencies satisfied.
  • Build and tests green per the global conventions in ../README.md (Section 3).