A small Android application can usually survive with screens, ViewModels, repositories, and a few API classes. Once the product becomes more complicated, however, technical layers alone may no longer describe what the software actually does.
Imagine a marketplace app containing payments, inventory, shipping, customer accounts, promotions, subscriptions, and order management. All of these areas use data, but they follow very different business rules.
This is where structuring Android applications around Domain-Driven Design can become useful.
Domain-Driven Design, commonly called DDD, encourages developers to organize software around the business domain instead of letting frameworks, databases, or APIs define the entire architecture.
For Android teams, that means thinking beyond packages such as ui, network, and database. The codebase can instead reflect concepts that product managers, developers, and domain experts actually discuss every day.
DDD does not replace Android architecture guidance. Used carefully, it can complement repositories, modularization, domain logic, and unidirectional data flow while giving complex business rules a clearer home.
Start With the Business Domain, Not Android Components
Android development naturally encourages thinking about technical components.
Developers see Activities, Composables, ViewModels, Room entities, Retrofit services, and Workers. Those pieces are important, but they should not automatically define the core structure of a sophisticated product.
DDD begins somewhere else: the business problem.
Consider a food delivery application.
Its important concepts might include:
Ordering → Delivery → Restaurant Management → Payments → Promotions
These are domains the business understands.
A promotion is not important because it comes from Retrofit. It is important because the company has rules determining eligibility, expiration, discounts, combinations, and customer restrictions.
This mindset changes architectural decisions.
Instead of building the application’s center around technical infrastructure, infrastructure becomes a supporting implementation for business capabilities.
That distinction becomes increasingly useful as the project grows.
Use Bounded Contexts to Separate Business Meanings
One of the most useful DDD concepts is the bounded context.
A bounded context defines an area where particular models and terminology have a consistent meaning.
Suppose an e-commerce app uses the concept of a Product.
Inside the Catalog context, a product may contain:
name, description, images, category, and displayPrice.
Inside Inventory, the concept may instead focus on:
sku, warehouse, reservedQuantity, and availableQuantity.
Trying to force both areas to use one enormous universal Product class usually creates unnecessary coupling.
DDD accepts that similar real-world concepts can have different models depending on context.
For Android, bounded contexts can influence package or Gradle module boundaries:
catalog
inventory
checkout
payments
account
This fits naturally with Android modularization guidance, which recommends loosely coupled, self-contained modules with clear purposes.
The result is a codebase organized around capabilities rather than one giant pool of shared models.
Model Entities Around Identity and Business Behavior
An entity is an object whose identity matters over time.
An Order, for example, remains the same order even when its delivery status changes.
Conceptually:
Order(id = "A103")
may move from:
CREATED → PAID → PREPARING → SHIPPED
The values change, but the order’s identity remains meaningful.
A common Android architecture mistake is treating domain objects as passive containers copied directly from API responses.
That often produces models containing dozens of nullable fields while business rules are scattered across ViewModels and utility classes.
DDD encourages richer domain models.
An Order might expose meaningful behavior such as:
cancel()
markAsPaid()
calculateRemainingBalance()
These operations can enforce business rules close to the data they govern.
The goal is not to put every function inside entities, but to prevent important business behavior from becoming random logic spread throughout the application.
Use Value Objects for Concepts Defined by Their Values
Not every domain concept needs identity.
Consider money:
Money(amount = 50, currency = "USD")
Two instances representing the same amount and currency can usually be treated as equivalent.
That makes Money a natural value object.
Other examples might include:
EmailAddress
Coordinates
DateRange
PhoneNumber
Percentage
Value objects can validate themselves during creation.
Instead of passing raw strings everywhere, an EmailAddress type can guarantee that code receiving it already has a validated domain concept.
This prevents primitive obsession, where business rules rely on generic strings, integers, and booleans whose meaning exists only in developer memory.
In Kotlin, immutable data class structures often work nicely for value objects.
Used sensibly, they make method signatures more expressive and reduce duplicated validation logic.
Protect Consistency With Aggregates
DDD uses aggregates to define boundaries around groups of related domain objects.
An aggregate has a root object responsible for protecting consistency.
Consider an Order containing several OrderItem objects.
Instead of allowing random parts of the app to modify individual items directly, changes can go through the Order aggregate root:
order.addItem(product, quantity)
The Order can then enforce rules such as quantity limits, duplicate products, pricing rules, or whether modification is allowed after payment.
This becomes useful when business invariants matter.
Without a clear aggregate boundary, one ViewModel might modify an item differently from a background synchronization task.
Now two parts of the application understand the same business rule differently.
Aggregates centralize those rules.
However, avoid creating gigantic aggregates containing every connected object.
A useful aggregate should protect a meaningful consistency boundary while remaining reasonably focused.
Repositories Connect Domain Logic to Data
Repositories fit naturally into both DDD and modern Android architecture.
Android’s architecture guidance describes repositories as entry points to the data layer that expose application data, centralize changes, resolve conflicts between data sources, and hide implementation details.
DDD takes a similar idea but frames repositories around domain concepts.
For example:
OrderRepository
might provide operations such as:
getOrder(orderId)
save(order)
observeActiveOrders()
The domain does not need to know whether orders originate from Room, Retrofit, GraphQL, or local files.
The infrastructure layer handles those details.
Conceptually:
Domain → Repository Contract
while infrastructure provides:
OrderRepositoryImpl → API + Room
This separation prevents network models and database entities from leaking into business logic.
If the backend changes later, the domain model can remain relatively stable.
That stability becomes particularly valuable in long-running Android applications.
Keep Android Framework Details Outside the Core Domain
A domain model should ideally understand business concepts rather than Android framework details.
For example, a pricing rule should not require an Activity, Context, NavController, or Compose state.
Why?
Because business logic becomes harder to test and reuse when it depends on Android-specific infrastructure.
Consider:
CalculateDeliveryFeeUseCase
Its job may be to evaluate destination, basket value, delivery method, and membership status.
That calculation should ideally work as ordinary Kotlin code.
Then it can run from a ViewModel, Worker, service, or potentially another platform without rewriting the fundamental rule.
Android’s own architecture guidance recommends clear boundaries and specifically encourages moving reusable or complex business logic into an optional domain layer when doing so reduces duplication and oversized classes.
DDD pushes this idea further by making the business model itself central.
The framework becomes something surrounding the domain rather than defining it.
Map Data Models Instead of Sharing One Model Everywhere
One of the more controversial parts of mature architecture is model mapping.
A complex application might have:
OrderResponse – network model
OrderEntity – Room persistence model
Order – domain model
OrderUiModel – presentation model
That looks repetitive.
For simple applications, it may indeed be unnecessary.
For complicated systems, however, these models represent different concerns.
The backend may rename a JSON field tomorrow. Database storage may need indexes or normalized relationships. The UI may need formatted dates and localized currency.
If every layer shares one model, a change in one area can ripple across the entire application.
Mapping introduces some boilerplate, but it also creates isolation.
Android’s guidance similarly emphasizes separation between UI state, application data, and underlying data sources rather than allowing infrastructure concerns to spread through the codebase.
The key is pragmatism.
Separate models when they protect real boundaries, not simply because an architecture diagram says you must.
Combine DDD With Multi-Module Android Architecture
DDD becomes particularly interesting in large multi-module projects.
Instead of structuring everything purely around technical layers:
presentation
domain
data
you can organize around business capabilities.
For example:
feature:catalog
feature:orders
feature:checkout
feature:payments
Each domain can then contain the layers it actually requires.
A more complex Payments area might contain dedicated domain, data, and presentation components, while a tiny Settings feature remains much simpler.
This approach scales better than forcing every feature into an identical architecture.
Android’s modularization guidance highlights maintainability, visibility control, ownership, and reduced coupling as major benefits of meaningful module boundaries. It also warns that excessive modularization can introduce unnecessary overhead.
DDD follows the same practical principle.
A bounded context should exist because the business has a meaningful boundary – not because the team wants twenty more Gradle modules.
Keep Use Cases Focused on Business Actions
Use cases can provide the connection between presentation logic and domain behavior.
Examples include:
PlaceOrderUseCase
ApplyPromotionUseCase
CancelSubscriptionUseCase
ConfirmDeliveryUseCase
These names describe things the business actually does.
That is preferable to vague classes such as OrderHelper or BusinessManager.
Android recommends keeping use cases focused on single responsibilities and adding them where they simplify complex or reusable business logic.
A use case might coordinate several repositories and domain objects.
For example, PlaceOrderUseCase could verify inventory, calculate pricing, validate payment eligibility, create an Order aggregate, and request persistence.
The ViewModel does not need to understand each business detail.
It simply asks the domain to perform a meaningful operation.
This keeps presentation code focused on state and user interaction rather than becoming the accidental home of the company’s business rules.
Do Not Turn DDD Into Architecture Theater
DDD can become extremely complicated when every concept from the books is copied into a project whether it is needed or not.
Not every Android application needs aggregates, factories, domain services, dozens of bounded contexts, and four representations of every object.
A simple note-taking app may work perfectly with UI and data layers.
Even Android’s official architecture guidance treats the domain layer as optional and recommends adapting architectural patterns to actual project requirements.
Use DDD where business complexity justifies it.
Payments, logistics, insurance, banking, marketplaces, healthcare platforms, booking systems, and enterprise workflows often contain rich business rules that benefit from stronger modelling.
A basic content viewer may not.
The best architecture is not the one containing the most patterns.
It is the one where developers can easily identify where an important rule belongs.
Structuring Android applications around Domain-Driven Design means allowing business concepts to shape the architecture instead of letting frameworks and databases control everything.
Bounded contexts separate areas with different meanings, entities preserve meaningful identity, value objects model important concepts, aggregates protect consistency, and repositories keep infrastructure behind stable domain boundaries.
Use cases then express actions using language the business can understand.
DDD becomes even more powerful when paired with sensible Android modularization and clear UI and data boundaries.
Start small. Pick one complicated feature in your current application and identify its real business language, rules, and boundaries.
If those concepts are currently scattered across ViewModels, APIs, and utility classes, that feature may be the perfect place to introduce domain-driven thinking.
