Strategic Review of D.Library Sprint 2: UsersModule, DTO Architecture, and the Inaugural Feature Roll‑out

Introduction

The D.Library platform, a collaborative digital repository for academic institutions across Central Europe, entered its second development sprint with a clear mandate: to solidify user management, introduce a robust data‑transfer contract layer, and deliver a tangible feature that would be visible to end‑users. While the sprint’s name—“UsersModule, DTOs and the First Real Feature”—suggests a narrow technical focus, the ramifications extend far beyond code. This article dissects the strategic choices made during Sprint 2, evaluates the architectural patterns adopted, and contextualises the outcomes against regional digital‑learning initiatives.

By analysing sprint velocity, defect density, and adoption metrics, we can gauge whether the technical decisions translate into measurable benefits for universities, libraries, and the broader knowledge‑economy of the region. The discussion proceeds through four lenses: the sprint’s objectives, the UsersModule’s architecture, the Data Transfer Object (DTO) strategy, and the first production‑ready feature. Real‑world analogues from other open‑source learning platforms are woven throughout to illustrate best‑practice alignment.

Main Analysis

1. Sprint 2 Objectives – From Ideation to Execution

At the outset, the product owner defined three concrete goals for Sprint 2:

1. Establish a self‑contained UsersModule that could be independently versioned and scaled.
2. Introduce a DTO layer to decouple domain entities from API contracts, thereby improving maintainability and security.
3. Deploy the first user‑facing feature—a registration and profile‑management workflow—within the live environment.

These goals were quantified using the Scrum framework. The sprint backlog comprised 42 story points, split as follows:

• UsersModule core services – 18 points
• DTO design and mapping – 12 points
• Feature implementation (registration flow) – 10 points
• Testing, documentation, and CI/CD integration – 2 points

Historical data from Sprint 1 indicated an average velocity of 35 points per two‑week cycle, with a defect leakage rate of 0.8 defects per 1,000 lines of code (KLOC). The team set a target velocity of 38 points for Sprint 2, anticipating a modest increase due to refined planning and the introduction of automated mapping tools.

2. Architectural Blueprint of the UsersModule

The UsersModule was engineered as a clean‑architecture slice, adhering to the “onion” model popularised by Robert C. Martin. The module consists of four concentric layers:

1. Domain Layer – Core business objects (User, Role, Permission) and domain services that encapsulate validation logic.
2. Application Layer – Use‑case interactor classes (e.g., CreateUserInteractor) that orchestrate domain operations.
3. Infrastructure Layer – Repository implementations using PostgreSQL and Redis for caching, plus an event‑bus adapter for asynchronous notifications.
4. Interface Layer – REST controllers built with NestJS, exposing endpoints such as /api/v1/users/register.

Key design decisions included:

• Dependency Inversion: Controllers depend on abstractions (interfaces) rather than concrete services, enabling mock‑based unit testing.
• Micro‑service readiness: The module is packaged as a Docker image with a dedicated Helm chart, allowing future extraction into a standalone authentication micro‑service.
• Scalability considerations: Read‑heavy operations (profile retrieval) are served from a read‑replica cluster, reducing primary DB load by an estimated 30 % based on load‑testing with JMeter.

These architectural choices echo patterns observed in the Open edX platform, where the auth component follows a similar layered approach to guarantee testability and future extensibility.

3. DTO Strategy – Bridging Domain and Presentation

Data Transfer Objects were introduced to address two recurring pain points:

1. Security exposure: Directly serialising domain entities risked leaking internal fields (e.g., password hashes, audit timestamps).
2. Versioning friction: API contracts evolve independently of domain models, and DTOs provide a stable contract surface.

Three DTO families were defined:

• Request DTOs – UserRegistrationRequestDto (fields: email, password, fullName).
• Response DTOs – UserProfileResponseDto (fields: id, email, fullName, joinedAt).
• Internal DTOs – Used for inter‑service communication via RabbitMQ, containing a minimal payload (userId, eventType).

Mapping between entities and DTOs leveraged the class‑transformer library, reducing boilerplate by 45 % compared with manual mapping. Automated tests confirmed that 100 % of DTO fields were correctly populated, and mutation testing (using Stryker) reported a mutation score of 92 %, indicating high resilience against regression.

From a governance perspective, the DTO layer was documented in an OpenAPI 3.0 specification, enabling downstream consumers (e.g., the mobile app team) to generate SDKs automatically. The specification now lists 12 endpoints, each with a documented request/response schema, and has already been adopted by the University of Bratislava’s mobile development team.

4. The First Real Feature – User Registration & Profile Management

Delivering a visible feature was essential to demonstrate sprint value to stakeholders. The chosen feature—a full registration flow—covers the following steps:

1. Submission of UserRegistrationRequestDto via POST /api/v1/users/register.
2. Server‑side validation (email format, password strength) using the class‑validator library.
3. Creation of a User domain entity, hashed with Argon2id (cost factor 4), and persisted to PostgreSQL.
4. Emission of a UserCreatedEvent to the event bus for downstream services (e.g., analytics, email notification).
5. Automatic