At Leantime, our mission has always been to create a work management platform that’s truly accessible for everyone, including neurodivergent users. What’s less obvious is how deeply this mission influences our technical architecture. Today, I want to share how our component-based, domain-driven design doesn’t just make for maintainable code – it directly supports cognitive accessibility for our users.
Beyond Surface-Level Accessibility
When most people think about accessibility in software, they focus on the user interface – high contrast options, keyboard navigation, and screen reader compatibility. These elements are crucial, but for neurodivergent users (those with ADHD, autism, dyslexia, and other cognitive differences), accessibility needs to go much deeper.
Many neurodivergent individuals process information differently. They may excel at deep focus on specific domains while struggling with context switching or managing information overload. Our architecture reflects this reality.
Domain-Driven Design for Cognitive Clarity
Leantime is built using a domain-driven design (DDD) approach with clear boundaries between components. Each domain – Tasks, Goals, Projects, Timesheets, Reports, and so on – operates as a self-contained component with well-defined interfaces to other parts of the system.
This architecture mirrors how many neurodivergent minds prefer to process information:
- Discrete chunks with explicit relationships rather than an overwhelming interconnected system
- Clear boundaries between different types of information
- Consistent patterns that reduce cognitive load
- Focused context that limits irrelevant information
Let’s look at what this means in practice.
Component Architecture in Action
1. Independent Domain Components
Each major functional area in Leantime is a separate domain with its own:
- Data models and repositories
- Business logic
- Controllers and services
- Views and templates
For example, our Tasks domain handles everything related to task management without needing to understand the details of how Goals or Timesheets work. It communicates with other domains through well-defined interfaces.
app/
├── Domain/
│ ├── Tasks/
│ │ ├── Controllers/
│ │ ├── Models/
│ │ ├── Repositories/
│ │ ├── Services/
│ │ └── Templates/
│ ├── Goals/
│ ├── Projects/
│ └── ...
This separation means that users can focus on one area of the application without being overwhelmed by the entirety of the system. Someone working in the Tasks view isn’t bombarded with Goal metrics or Project details unless they explicitly request that context.
2. Consistent Interface Patterns
We maintain consistent patterns across domains to reduce the cognitive load of learning new sections of the application. For example:
- List views follow the same filtering and sorting patterns
- Detail views maintain consistent layouts and action locations
- State changes (create, update, delete) work the same way across domains
This consistency means that once a user learns how to work with tasks, they can apply that knowledge to goals or milestones with minimal additional cognitive effort.
3. Context-Aware Information Display
Our architecture enables us to be selective about the information we present at any given time. Rather than showing all possible data, we carefully manage context:
- Dashboard widgets show focused summaries with clear paths to details
- Related items are accessible but not automatically displayed
- Views adapt to the current workflow context
For example, when looking at a task, you can easily access the related milestone – but you don’t have to process that relationship until you need it.
Benefits for Neurodivergent Users
This architectural approach creates several specific benefits:
Reduced Cognitive Overload
By separating concerns and focusing information, we reduce cognitive overload – a common challenge for many neurodivergent users. Rather than trying to process an entire system at once, users can engage with one domain at a time.
Support for Hyperfocus
Many people with ADHD and autism experience hyperfocus – intense concentration on specific tasks. Our domain separation supports this work mode by creating clean, focused contexts free from distractions.
Clearer Mental Models
Our explicit relationships between domains help users build clearer mental models of their work. Rather than a tangled web of connections, they can understand discrete components and how they relate.
Predictable Navigation Paths
The consistent patterns across domains create predictable navigation paths, reducing anxiety and cognitive effort when moving between different parts of the system.
Developer Benefits
Interestingly, these same architectural choices that benefit neurodivergent users also create advantages for developers contributing to Leantime:
Focused Contribution Areas
New contributors can focus on one domain without understanding the entire codebase. This lowers the barrier to entry for participation in our open source community.
Clear Integration Points
The well-defined interfaces between domains make it easier to understand how components interact and how to extend the system.
Testable Components
Domain separation makes our components more easily testable in isolation, improving code quality and stability.
Evolving Together
As we continue to develop Leantime, we’re constantly refining our architecture to better support both neurodivergent users and our developer community. Our plugin system extends these principles even further, allowing for even cleaner separation of concerns and more focused user experiences.
We believe that truly accessible software requires thinking beyond surface-level features to the fundamental architecture that shapes how users interact with information. By building component-based systems with clear boundaries and explicit relationships, we can create software that works better for everyone – especially those whose minds work differently.
I’d love to hear your thoughts or questions about our architectural approach. Join our Discord community to continue the conversation!
