Getting Started 🚀
Own the Domain. We Handle the Orchestration.
🔍 Why does Domaintrix exist?
The software industry is saturated with theories on architectural best practices but lacks practical and complete implementations that serve as clear references for real-world projects.
Books like Domain-Driven Design, Design Patterns, Clean Architecture, and many others offer foundational concepts — but none present a final architectural structure suited for modern, complex systems.
Domaintrix was created to fill that gap: a project that materializes those concepts, organizes patterns, and provides a living, functional, and extensible structure for building robust, change-ready systems.
🌟 What problems does Domaintrix solve?
- Defines how to structure systems to be scalable, adaptable, and high-performance from day one, without needing to worry about the infrastructure that supports it.
- Reduces decision fatigue and common mistakes when starting new projects.
- Keeps your focus on the domain, not the infrastructure.
- Eliminates accidental coupling, enabling safe and continuous evolution.
- Provides a concrete foundation for teams that seek clarity, predictability, and architectural discipline.
⏱️ How and when did it start?
Domaintrix began in 2021, born out of a need to solve recurring architectural challenges in enterprise systems through a practical and scalable approach. That was when the pattern known as Domain Mediator emerged — a combination of the Mediator (GoF) pattern and DDD concepts — with the purpose of relieving developers from architectural overhead and allowing them to focus purely on the domain.
Over time, this pattern was applied and evolved across multiple projects, continuously validated by other tech leads and architects. After a period of stability and maturity, it became clear that the pattern was ready to become something greater: a reusable standard, open to the community, and capable of serving as a reference for teams and companies.
🧪 Why the name Domaintrix?
The name Domaintrix combines "domain" (from Domain-Driven Design) with Matrix, referencing the idea that the domain exists within a system it is unaware of — a hidden orchestration layer that makes everything work. Like in the movie, there's an architect behind the scenes. In this case, that's what Domaintrix provides. (And yes, it's good for the domain to be in the Matrix 😎)
🧠 What makes Domaintrix unique?
- It’s about architecture, not technology: while it starts with a .NET implementation, Domaintrix is language-agnostic by design.
- Extensible and adaptable by nature: every architectural decision can be extended, overridden, or replaced without breaking the core.
- Opinionated but modular: it offers strong guidance while remaining flexible for custom needs.
- Built from real-world experience: designed by professionals who understand what works in complex, dynamic environments.
- Stack-independent: each language will have its own implementation, following the same architectural model.
⚙️ How should Domaintrix be used?
Domaintrix does not ship a ready-made application. Instead, it offers a set of reusable building blocks and a reference structure to help you start projects with a solid, validated, and extensible foundation.
It is based on well-established patterns, including:
- Domain-Driven Design (DDD): Entities, Value Objects, Repositories, Aggregates, Factories, Specifications, etc.
- CQRS: clear separation between commands and queries, each with their own handlers.
- Pluggable Event Bus: native support for Kafka, RabbitMQ, Azure Service Bus, or in-memory alternative.
- Clean Architecture: clear separation between domain, application, infrastructure, and presentation layers.
- Domain Mediator: a central orchestrator for domain operations:
- Notifications
- Command executions
- Query executions
- Event publication
- Authorization based on context
- Mapping notifications to HTTP responses
- Vertical Slice Architecture: organizing code by feature instead of layers.
- Isolated Bounded Contexts: each business domain operates independently and communicates via events.
- Optional Event Sourcing: compatible with event-sourced systems.
- Dependency Injection: all implementations are decoupled from the domain.
Additionally, Domaintrix is compatible with many other common design patterns not directly implemented but easily adoptable:
- Builder Pattern: for fluent construction of complex objects.
- Decorator Pattern: for runtime extension of behavior.
- Observer Pattern: for reactive, event-based communication beyond the core Event Bus.
- Chain of Responsibility: useful for pipelines such as validation, authorization, or transformation.
📊 Design Principles
Domaintrix adheres to the most important software design principles, ensuring robustness, maintainability, and clarity:
- SOLID: full application of all five principles in code structure and boundaries.
- DRY (Don't Repeat Yourself): logic and structure are reused where appropriate.
- YAGNI (You Aren't Gonna Need It): we avoid overengineering, but leave room for extension.
- KISS (Keep It Simple, Stupid): simplicity is the foundation of good architecture.
📊 Telemetry and Observability
Domaintrix is built with observability in mind from the start, with integration points for tracing and diagnostics across domain, application, and infrastructure layers.
We recommend using OpenTelemetry, an open, vendor-neutral standard that allows you to:
- Trace commands, queries, and events with context.
- Export metrics, logs, and traces to tools like Jaeger, Prometheus, Grafana, Elastic, or Azure Monitor.
- Instrument services without coupling to the implementation.
- Standardize distributed tracing and monitoring.
All Domaintrix modules are ready to be instrumented with minimal effort, giving you visibility without compromising simplicity or performance.
🚀 Next Steps
Domaintrix is already complete and tested in private environments. We are now refactoring it to be more accessible to the open-source community and applying structural updates.
The codebase will be published incrementally, and documentation and repositories will be updated as each piece is released.
Currently, the implementation is in .NET, but we plan to support other languages after the first official release. Developers are welcome to contribute with other stacks even now.
Domaintrix includes a real-world reference application called Tastrix — a task management system with multiple workspaces and per-workspace permission control. Users can manage personal tasks in private workspaces, collaborate in shared team spaces, and view all their responsibilities in one place, streamlining prioritization.
Links to the Tastrix project will be added here soon.
To follow progress, check out the Domaintrix GitHub Projects, where you can see our roadmap and execution in real time.
🤝 How to contribute
Want to join the Domaintrix project? Amazing!
Here’s how to contribute following open-source best practices:
- Read the Contributing Section (coming soon) — it will explain contribution guidelines, code style, and approval process.
- Pick an issue labeled
good first issue,help wanted, ordiscussion. Great places to start. - Comment on the issue to express interest. This helps us avoid duplicated work.
- Fork the repo and create a descriptive branch.
- Submit a pull request to the
mainbranch or as directed in CONTRIBUTING.md.
You can also suggest architectural improvements, fix docs, organize packages, or help with multi-language implementations.
If you want to start a new implementation in another language, open an issue or discussion to align on structure and patterns.
All contributions are welcome, as long as they follow our core principles: clarity, responsibility, predictability, and domain focus.
Thanks for joining the journey!
👤 Creator
This project was created and is maintained by Fillippe Prata.
If you'd like to talk about software architecture, best practices, or collaborate more directly, feel free to connect.