Technical assessment: make ClearLend ready to build

01

What this assessment is for

A technical assessment is the bridge between a promising product idea and a buildable system. It is not a document written to make the project look complicated. It is a way to expose the decisions that would otherwise appear as surprises during development. ClearLend has multiple roles, sensitive evidence, financial events, state changes, fees, notifications and operational teams. A senior developer must understand those pressures before choosing a project template or creating a database table. This phase records the evidence behind the recommendation, makes assumptions visible, and narrows the first delivery so that the team can prove the approach safely.

• Understand the business capabilities and their boundaries.
• Translate product language into testable behaviour.
• Set measurable expectations for security, performance and reliability.
• Record risks and decisions instead of hiding them in code.
• Choose a first slice that demonstrates the architecture without attempting the whole platform.

02

Assessment scope and system boundaries

The first release is a managed lending marketplace, not a bank and not an attempt to model every financial regulation in one tutorial. ClearLend connects vetted borrowers and lenders, manages products and applications, records decisions, coordinates funding and servicing, and gives operational teams the evidence they need to work safely. The boundary includes the workflows and records ClearLend owns. It does not pretend to own a payment provider, an external credit bureau, a bank account, or a government register. Those systems are dependencies with contracts, failures and reconciliation states. Naming the boundary prevents the team from promising capabilities that the first architecture cannot support.

• In scope: onboarding, vetting, product management, applications, offers, commitments, payments, servicing, support, compliance and reporting.
• External dependencies: identity, payment provider, email or SMS delivery, document storage and optional credit data.
• Out of scope for the first slice: live money movement, real credit decisions, production compliance approval and automated risk scoring.
• Synthetic users, documents and payments are used throughout the educational build.

03

Functional requirements: what the product must do

Functional requirements describe behaviour that a person or an authorised system can observe. Each requirement should identify the actor, goal, preconditions, main path, alternative paths, failure cases, permission, audit entry and notification. This turns a broad statement such as “support lending” into slices that can be estimated and tested. The requirements below are the first catalogue, not a promise that every feature will be implemented immediately.

• A borrower registers, completes onboarding and submits evidence for review.
• A CRM reviewer approves, declines or requests more information, with a recorded reason.
• A completed assessment creates or updates a borrower credit limit.
• A lender creates, edits, publishes, pauses and retires a loan product.
• A borrower browses only products they are eligible to see and submits an application.
• A reviewer records an offer with exact terms; the borrower accepts, declines or lets it expire.
• A lender records a commitment and the system creates the correct loan and repayment records.
• Finance reconciles provider outcomes, fees, adjustments and unknown payment states.
• Support staff manage cases and link communications to the affected application or loan.
• Compliance staff can retrieve evidence, decisions, changes and audit history for inspection.

04

Non-functional requirements: how well it must work

A lending application can complete the happy path and still be unsafe or unusable. Non-functional requirements make quality part of the design. They should be measurable enough to test, observe or review. The exact thresholds would be agreed with the business; the examples below show the level of precision expected from the assessment.

• Security: every API action checks identity, role, resource ownership and current state; sensitive evidence is encrypted and never written to ordinary logs.
• Performance: common dashboard reads are paginated and meet an agreed response target under representative load; commands do not perform unnecessary external calls.
• Reliability: retries are safe through idempotency keys; provider timeouts create an explicit pending or unknown state instead of guessing success.
• Consistency: financial events, balances and audit entries are committed atomically where they belong to one transaction.
• Auditability: approvals, declines, fee changes, corrections and privileged actions record actor, time, reason and affected record.
• Maintainability: domain rules can be tested without a web server, and modules expose deliberate contracts rather than shared tables.
• Accessibility and privacy: important journeys work by keyboard, error messages are understandable, and data collection and retention are explicit.
• Observability: logs, metrics, traces, correlation IDs and health checks allow an operator to diagnose a failed workflow without reading customer documents.

05

Risks, assumptions and questions to resolve

A good assessment is honest about uncertainty. Assumptions are not weaknesses; hidden assumptions are. Each item should have an owner, an impact, evidence needed and a date for review. Some questions are commercial or regulatory and cannot be solved by a developer alone, but the architecture should make their effect visible. For example, whether ClearLend is a marketplace or lender of record changes agreements, reports, payment responsibilities and controls.

• Business model: is ClearLend only a marketplace, or can it lend its own capital?
• Jurisdiction: which countries, currencies, tax rules and consumer protections apply?
• Funding model: does one lender fund a loan, or can many commitments make up one loan?
• Credit decision: which evidence and external data are required, and who owns the decision?
• Payments: what provider callbacks exist, and how is an unknown result reconciled?
• Data: how long are documents, decisions, communications and financial records retained?
• Operations: what must happen if a product is paused, a lender exits, or the platform enters a wind-down process?
• Scale: which workload is expected first, and what evidence would justify splitting a module into a service?

06

Architecture decision: start with a modular monolith

The recommendation is a modular monolith using vertical slices. ClearLend has several capabilities, but early delivery benefits from one deployable unit, one operational boundary and straightforward transactions. Modules still have clear ownership of commands, queries, domain rules and persistence mappings. This avoids the accidental coupling of a traditional shared-layer application without introducing distributed transactions, network failures and deployment coordination before the product needs them. A module can be extracted later if scale, team ownership or isolation becomes a proven requirement. The decision is deliberately reversible at the capability boundary.

• One ASP.NET Core host keeps local development and deployment understandable.
• Feature folders keep the code organised around user behaviour rather than technical types.
• Modules communicate through explicit application contracts and domain events.
• Infrastructure details stay behind ports so the domain is not tied to EF Core or a payment SDK.
• Extraction into a service is considered when evidence shows a genuine operational benefit.

07

Solution structure and dependency direction

The project structure should make an unsafe dependency difficult to introduce. The API translates HTTP and authentication context. The application layer coordinates a use case and a transaction. The domain protects invariants. Infrastructure implements persistence and external integrations. A dashboard query may read a projection shaped for the screen, but it cannot bypass the command that changes a financial or workflow state. This is a practical boundary that a reviewer can enforce in code review.

• Web depends on application contracts, not database entities.
• Application depends on domain and ports, not concrete providers.
• Infrastructure implements ports and owns EF Core configuration.
• Tests prove boundaries rather than only checking private methods.

src/
  ClearLend.Api/             // endpoints, auth, ProblemDetails
  ClearLend.Application/    // commands, handlers, DTOs, ports
  ClearLend.Domain/          // aggregates, value objects, rules
  ClearLend.Infrastructure/ // EF Core, files, payments, messaging
  ClearLend.Contracts/       // public request and response contracts
  ClearLend.Worker/          // reminders, reconciliation, outbox delivery

tests/
  ClearLend.Domain.Tests/
  ClearLend.Application.Tests/
  ClearLend.IntegrationTests/
  ClearLend.ContractTests/

08

Architecture decisions we will record

The assessment should produce short architecture decision records. Each record explains context, options considered, decision, consequences and the evidence that would make us revisit it. This makes the project useful to readers who need to defend a design in a review, not just copy a folder structure. Initial records include the modular monolith, vertical slices, SQL Server with EF Core, policy-based authorisation, an outbox for reliable follow-up work, immutable financial events and OpenTelemetry-compatible observability.

• ADR-001: modular monolith before distributed services.
• ADR-002: vertical slices for feature ownership and delivery.
• ADR-003: SQL Server and EF Core for transactional records.
• ADR-004: immutable financial events with append-only corrections.
• ADR-005: outbox messages for notifications and integration work.
• ADR-006: policy and resource-based authorisation at the application boundary.
• ADR-007: structured logs, metrics and traces without sensitive document data.

09

Choose the first vertical slice

The first implementation should be a borrower creating a draft application and submitting it for review. It is valuable enough to prove authentication, ownership, validation, state transitions, persistence, audit and an Angular interaction. It is small enough to complete without pretending to implement the entire lending lifecycle. The slice should leave a working path through every boundary: HTTP request, application command, domain method, database transaction, audit history, outbox event, response and tests.

User story
As a vetted borrower, I want to submit my completed application
so that an authorised reviewer can assess it.

Acceptance examples
Given a borrower owns a draft and required evidence exists
When the borrower submits the application
Then the status becomes Submitted
And an audit entry and review event are recorded
And the response tells the borrower what happens next

010

Define the technical quality gate

The slice is not done when the endpoint returns 200. It is done when the product promise is protected by code and evidence. The quality gate makes review fair: another engineer can run the tests, inspect the migration, trigger a failure and understand the decision. It also gives the later phases a stable foundation instead of allowing each new feature to invent its own rules.

• Happy path creates the expected state, history and outbox record.
• Missing evidence is rejected by the domain, not only by the UI.
• A borrower cannot submit another borrower's application.
• A duplicate retry does not create a duplicate submission or notification.
• Concurrent submissions produce one valid result and one clear conflict.
• API failures use consistent ProblemDetails responses and do not expose internals.
• Unit, integration and authorisation tests run in CI.
• Logs contain a correlation ID and outcome without sensitive document content.
• A short runbook explains local setup, migration, test execution and troubleshooting.

011

What Phase 2 gives the next phases

This assessment gives the project a disciplined starting point. Phase 3 develops the solution architecture, role experiences and Azure delivery design. Phase 4 begins by explaining the backend layers, then builds the foundation, domain model and borrower draft journey in reviewable steps. Phase 5 can complete submission and reviewer visibility. We have not attempted to solve every commercial or regulatory question, but we have made the important uncertainty visible and chosen a safe boundary for learning.

• A functional requirements catalogue tied to real actors and workflows.
• Measurable quality expectations for security, performance and reliability.
• A risk and assumption register with questions that need business decisions.
• Architecture decisions with trade-offs instead of unexplained patterns.
• A modular solution structure and dependency direction.
• A first vertical slice with a definition of done and testable evidence.