Designing a Production-Oriented Application from Mobile UI to Database

The Problem

When transitioning from building simple prototype applications to production-oriented software, the architecture must change fundamentally. A prototype can connect a mobile UI directly to a database like Firebase, bypassing strict backend validation. A production application cannot. It requires clear separation of concerns, strict validation, and the ability to scale different components independently.

Context

The goal is to design a system where a Flutter mobile client securely interacts with a Java Spring Boot backend, which in turn manages business logic and talks to a relational database (MySQL).

The flow looks like this:

Mobile Client 
  ↓ (JSON over HTTPS)
API Gateway / Controller 
  ↓ (DTOs)
Service Layer 
  ↓ (Entities)
Repository Layer 
  ↓ (SQL)
Database

What I Tried (The Anti-Pattern)

Early in my learning journey, I tried building “fat controllers.” The API controller would receive an HTTP request, open a database transaction, parse the JSON, write custom SQL queries, and return an HTTP response all in one massive function.

What Failed

This failed spectacularly as the application grew.

1. Testing: I couldn’t test the business logic without mocking the entire HTTP request/response cycle.
2. Reusability: When a scheduled background job needed to update user records, I had to duplicate the code from the controller because the controller was tightly coupled to HTTP requests.
3. Security: Raw data structures were passed directly back to the client, exposing internal database IDs and password hashes.

What Worked & Technical Explanation

I implemented a strict N-Tier Architecture, separating concerns at every layer.

1. The API Layer (Controllers) Controllers only care about HTTP. They receive a request, validate the incoming JSON against a Data Transfer Object (DTO), and immediately pass the data to the Service Layer.

2. The Service Layer (Business Logic) This is the brain of the application. It knows nothing about HTTP or SQL. It receives validated DTOs, applies business rules (e.g., “A user cannot register if they are under 18”), and coordinates with the Repository Layer.

3. The Repository Layer (Data Access) This layer handles the actual database communication using an ORM like Hibernate or raw SQL queries. It returns Domain Entities.

4. External Services If the application needs to send an email or process a payment, the Service Layer calls an Interface (e.g., EmailService). The actual implementation (e.g., SendGridEmailServiceImpl) is injected.

Lessons Learned

Separation of concerns is not just theoretical computer science overhead. It is the only way to build software that can survive changing requirements. By decoupling the HTTP layer from the business logic, I can swap out the web framework. By decoupling the business logic from the database, I can swap out the ORM.

What I Would Do Differently

I would introduce an API Gateway pattern earlier if the system required microservices. However, for most of the production applications I build, a well-structured modular monolith using the exact architecture described above is significantly more efficient to deploy and maintain.