XP-R — Preparing the Foundations (Tech Notes)

Aviso: La mayoría de las actualizaciones estarán en inglés, pero iré publicando también entradas resumen en español cada cierto tiempo.

This post complements the previous entry (XP-R — Preparing the Foundations), focusing on the technical implementation details behind XP-R’s architecture, module structure, and Identity module setup.

Technical Notes

Some additional implementation details that were established during this

phase:

Models and module organization

• Models are placed inside a models/ package using pluralized
  files to group related classes.\


• This allows multiple related models per file without breaking Django
  conventions.\


• It also helps avoid circular dependencies while keeping the
  structure scalable.

Identity module configuration

default_auto_field = 'django.db.models.BigAutoField' is explicitly

configured to prevent issues with very large datasets in the future.

Nested Django apps

Because apps are inside the modules directory, a few Django-specific

adjustments are required.

INSTALLED_APPS explicitly imports the AppConfig:

modules.identity.apps.IdentityConfig

Using only modules.identity relies on Django's implicit discovery

mechanism, which can sometimes produce confusing behavior in more

complex structures.

General guidelines used in the project:

• Python imports use the full path: modules.identity...
  


• The name variable in apps.py also uses the full path:
  modules.identity
  


• Database references and Django metadata use the short label:
  identity
  

Shared model utilities

A base abstract model called TimeStampedModel was introduced in the

Core module, providing:

• created_at
  


• updated_at
  

This keeps models consistent across the project while avoiding repeated

boilerplate.

API serialization strategy

The first serializer implemented was UserSerializer in the Identity

module.

The project follows two rules for API design:

• incremental database IDs are never exposed
  


• only UUID-based identifiers are used externally

Serializers are organized per module inside a serializers/ directory,

using pluralized filenames such as:

user_serializers.py

This prevents monolithic serializer files and helps keep the API layer

modular as the platform grows.