diegofc17/sdg

1. Overall shape

- This is a single Django monolith organized into four domain apps under apps/: core, accounts, documents, and audit.

- The project uses the standard Django runtime entry points: manage.py, config/asgi.py, config/wsgi.py, and global settings/routing in config/.

2. Request routing

- Incoming HTTP requests flow through config/urls.py into each app’s urls.py.

- Each app then dispatches to its own views.py, which renders HTML templates rather than exposing a JSON API.

3. Presentation layer

- UI is server-rendered with Django templates in templates/.

- Shared layout lives in templates/base.html; app-specific pages are split by feature area: home/dashboard, login/signup, documents, expedientes, and audit.

- Static assets are simple front-end resources in static/ (css/app.css, images).

4. Core app

- apps/core/ is the lightweight shell for landing pages and dashboard-style views.

- It acts as the entry point for authenticated/unauthenticated navigation rather than containing domain logic.

5. Accounts subsystem

- apps/accounts/ owns user-facing account logic: forms, views, models, signals, and URL routes.

- The presence of templates/registration/login.html and signup.html indicates Django authentication is extended with custom registration/login flows.

- signals.py suggests post-save or profile-creation behavior tied to user accounts.

6. Documents domain

- apps/documents/ is the main business subsystem.

- It contains models, forms, views, templates, and a rich migration history, indicating an evolving domain model.

- The templates show user workflows for document creation, detail views, lists, and expediente management.

7. Document lifecycle and metadata

- The migration names reveal the domain entities and their evolution: Documento, Expediente, SerieDocumental, SubserieDocumental, TipoDocumental, and later TRD/TVD-related structures.

- Fields added over time include document classification, dates, status, support medium, asunto, and expediente linkage.

- This suggests documents are cataloged and classified against an archival/records-management taxonomy.

8. Audit subsystem

- apps/audit/ handles audit logging or traceability views/forms/models.

- There are dedicated templates and signals, implying events are captured automatically and then presented in an audit list UI.

- apps/audit/utils.py likely supports formatting or aggregation of audit entries.

9. Data flow between subsystems

- Typical flow is: user authenticates through accounts, navigates via core, creates or manages records in documents, and actions are recorded in audit.

- Models and signals are the main integration mechanism between these apps, with the audit layer observing domain events rather than driving them.

10. Persistence and schema management

- State is stored in Django models backed by a relational database, with schema evolution managed entirely through migrations.

- The long sequence of documents/migrations/ files shows the document schema is central and has been iteratively refined.

11. Operational tooling

- apps/documents/management/commands/import_trd.py is an offline data-import/admin command used to load TRD reference data.

- This indicates the application depends on controlled reference catalogs, not just user-entered data.

12. Administrative surface

- Multiple admin.py files indicate the Django admin is used as a back-office management interface for the main models.

- This is likely important for maintaining taxonomy/reference data and reviewing records without going through the end-user screens.

13. Boundary summary

- The clearest architectural boundaries are:

- UI/rendering: templates + views

- Identity: accounts

- Records management: documents

- Traceability: audit

- Shared shell/routing: core + config

- There is no sign of a separate frontend, API gateway, or external service dependency in the repository structure.

14. Likely runtime footprint

- The app runs as a standard Django site via runserver in development, and can be deployed through WSGI or ASGI.

- media/ is referenced in the README, so file uploads are part of the architecture even though the storage backend is not shown here.