maituyet04/datn_2026_dscms_luumaituyet

1. This is a Django-based backend for a dermatology/spa clinic management system. The repository is organized as a layered application: HTTP/API boundary, application services, feature/use-case handlers, repositories, and domain entities/DTOs.

2. The runtime entry points are the standard Django manage.py, plus config/asgi.py and config/wsgi.py. config/settings.py, config/urls.py, and src/api/urls.py define the application wiring and request routing.

3. The HTTP/API layer lives under src/api. It contains endpoint modules for each business area: appointments, attachments, audit, auth, customers, invoices, medical records, notifications, prescriptions, resources, services, spa workflows, treatments, visits, and wallets. Shared API concerns such as exception handling, pagination, permissions, response formatting, and serializers are also centralized here.

4. The application core is split into src/services and src/features. The service layer appears to coordinate business rules and cross-cutting operations such as auth, payments, check-in, escalation, transactions, and clinic workflows. The feature folders represent use-case implementations like “create appointment”, “start examination”, “create invoice”, “add payment”, “deduct wallet”, and similar actions.

5. Data access is isolated in src/repositories. Each major aggregate has its own repository module, which suggests the system keeps persistence logic separate from business logic. The repositories likely wrap Django ORM operations against the database schema in database/database.sql.

6. The domain model is expressed in src/entities. These modules define core business objects such as Customer, Appointment, Visit, Invoice, MedicalRecord, Prescription, Wallet, Service, Treatment, Resource, Notification, Attachment, User, and Audit. This layer is the main boundary for business state and relationships.

7. DTOs in src/dtos provide structured data transfer between API/services/features/entities. They likely shape inbound/outbound payloads and help decouple the HTTP contract from the internal domain model. The presence of dedicated DTOs per aggregate indicates a strong separation between transport and business objects.

8. The main business subdomains are:

- Patient/customer management

- Appointment scheduling and check-in

- Visit flow and clinical orders/examinations

- Medical records and prescriptions

- Invoicing, payments, refunds, and wallet balances

- Service catalog and treatment planning

- Spa/dermatology session workflows

- Audit logging and notifications

9. Several workflows span multiple subsystems. For example, an appointment can be created, updated, checked in, and converted into a visit; a visit can create clinical orders and progress through examination to completion; medical record actions can create prescriptions or lock records; invoicing can interact with wallet/payment logic; spa-related actions can escalate to a doctor and record skin conditions.

10. Cross-cutting utilities are collected under src/utils, including code generation, constants, date and phone helpers, file handling, logging, permissions, validators, pagination, and response helpers. These support consistent behavior across the API and business layers.

11. src/services/transaction.py suggests explicit transaction handling around multi-step business operations. That matters architecturally because several clinic workflows likely need atomic updates across multiple tables or aggregates.

12. The repository also includes src/admin.py, which indicates Django admin integration for internal management, and src/apps.py/src/migrations for app registration and schema evolution. pyproject.toml and uv.lock show the project is managed with uv and Python packaging tooling.

13. For an architecture diagram, the clearest flow is: HTTP request enters Django/API routing, API modules validate/serialize and enforce permissions, services/features execute the business use case, repositories persist/retrieve entities, and responses are shaped back through serializers/response helpers. The database is the primary external persistence boundary shown in the repo.