IbisQuest engineering
Architecture, decisions, and practices supporting an OKR platform ready to evolve.
Engineering details
IbisQuest’s architecture aims to keep clear boundaries, simple operations, and a foundation ready to evolve. These are the technical criteria and decisions supporting the product.
Technical overview
Architecture
Clear boundaries for evolution
The system combines independent modules, feature-oriented organization, and read/write separation to keep growth under control.
SaaS product
Organizations with their own boundaries
The product includes organizations, teams, contributors, roles, and permissions within a multitenant workspace.
Quality
Verifiable decisions
Quality is validated at several levels: architectural boundaries, component collaboration, and isolated behavior.
Architecture and boundaries
Interface and API
Blazor, ASP.NET Core, and REST APIs expose the product experience and input contracts.
Feature-oriented use cases
Feature slices keep each workflow close to its rules and collaborators.
Domain and business rules
Domain boundaries hold the rules for configuring, aligning, and tracking objectives.
Persistence and integrations
Entity Framework, Azure SQL, Microsoft Entra, and Azure Communication Services support data, identity, and invitations.
Decisions and tradeoffs
| Decision | Why | Benefit | Tradeoff and review |
|---|---|---|---|
| Modular monolith | Keep operations simple while the product grows. | Deployment and module collaboration with lower operational complexity. | Less independence than microservices; review if modules need independent scaling or deployment. |
| CQRS | Separate read and write needs by use case. | More explicit flows and models tailored to each operation. | More code and possible duplication; review if complexity outweighs the benefit. |
| Multitenancy | Support multiple organizations within the product. | A SaaS model with centralized organization boundaries. | More authorization and isolation complexity; review controls if the trust model changes. |
| Synchronous messaging | Keep collaboration between modules explicit. | Flows that are easy to follow inside the monolith. | Temporal coupling; review if long-running processes or asynchronous resilience needs emerge. |
| REST APIs | Separate clients and services through familiar contracts. | Interoperability and independent interface evolution. | Contracts must be maintained; review versioning if consumers grow. |
| Entity Framework and relational persistence | Organize data access and preserve transactional consistency. | Productivity and a relational model suited to current flows. | Coupling to the relational model; review if volume or query needs change. |
Technology stack
Application
Experience and services
The application uses .NET, ASP.NET Core, Blazor, and REST APIs to organize the experience and use cases.
Data
Organized persistence
Entity Framework together with Unit of Work and Repository organize access to SQL Server and Azure SQL.
Cloud and integration
Services prepared for a real product
Identity and access use Microsoft Entra, while invitation emails use Azure Communication Services.
Conceptual security and quality
Identity and multitenancy
Identity is managed with Microsoft Entra. Organizations, roles, and permissions are part of the workspace access model, maintaining isolation between organizational contexts.
Testing by level
Architecture Testing validates boundaries, Integration Testing validates collaboration between components, and Unit Testing validates isolated behavior.
Ways of working
Implementation principles
SOLID and Clean Code guide implementation. Synchronous messaging between modules keeps collaboration inside the monolith explicit.
Assistance tools
Codex and GitHub Copilot accelerate exploration, documentation, and repetitive tasks, while decisions and final validation remain human responsibilities.
Want to return to the product narrative?