Jan Mikoláš
Layered application
Where responsibility and transactions belong
- UI: HTTP, Console, or message handler
- Application: use case and transaction boundary
- Domain: rules, entities, and value objects
- Infrastructure: database, queue, and framework
Back to skills
Way of working
Application architecture
I do not choose architecture by the name of a pattern, but by the complexity of the problem. The goal is clear boundaries, safe changes, and a solution proportionate to the application.
Structure should make change easier, not more complex.
In larger applications developed over the long term, I separate UI, Application, Domain, and Infrastructure. Domain rules are then not attached to a framework, database, or a particular API, and each part has clearer responsibility.
That does not mean every part of an application needs full Clean or hexagonal architecture. For a simple problem with a few inputs and no complex rules, a direct service-based solution is often clearer and less costly to maintain.
Not familiar with a term? Read a concise explanation in the glossary.
How my approach evolved
From Controller → Facade → Service to proportionate boundaries.
-
Earlier
Controller → Facade → Service
This style gave my earlier projects a clear structure. Over time, with more complex flows and more integrations, I found that responsibilities and dependencies needed stronger boundaries. -
More complex system parts
Separating business rules from technology
When an application has more use cases, integrations, or rules, I separate domain and application logic from HTTP, the database, and the framework. It then becomes easier to test, change, and extend. -
Today
Clean and hexagonal principles when needed
I use principles of Clean Architecture, DDD, dependency injection, and ports with adapters. I am not aiming for a label or a number of layers, but for clear responsibility and controlled dependencies. -
A pragmatic choice
When a simpler solution is better
A small module without complex rules does not need a separate domain model, ports, or several adapters. In that case, I choose a direct structure and add complexity only when it solves a real problem.
Boundaries and dependencies
Business rules inward, technical details outward.
Layers are not an end in themselves. They show how dependencies may flow: UI calls an application use case, the use case uses the domain, and technical details implement the interfaces the application needs.
I adjust the approach according to the risk of change, application lifetime, number of integrations, and the team’s ability to maintain the architecture in practice.
Port and adapter
An example of connecting an external data source
- Application: pickup-point import
- Port: CarrierPointSource
- Adapter: carrier XML feed or API
- Infrastructure: HTTP client, parser, and storage
Public example
Layers and architectural checks in practice
Principles I use
Architecture based on application needs
- Clean Architecture
- DDD
- Hexagonal Architecture
- Dependency Injection
- SOLID
- KISS
- YAGNI
- Deptrac
Need clearer application boundaries, not more layers?
I can help assess where architecture brings real value and where it is better to keep a simple, readable solution.