Alex KlausDeveloper  |  Tech Lead  |  Architect
Yet Another Bug Tracker (YABT). Start of a series
15 October 2020

Yet Another Bug Tracker (YABT). Start of a series

NoSQL is not hard, it’s different. And to show that, RavenDB and I kick off a new series of articles dedicated to building an enterprise application leveraging the .NET Core + RavenDB bundle.

We want to give as much of practical knowledge as possible, so let’s build a real-ish enterprise solution and explain various interesting aspects in the articles along the way. Of course, making everything open source and under the MIT license. The solution will show not only the database part but also domain services, tests, API and the front-end. The goal is to show how various DB features play out all the way through the API to the UI.

And we will follow the best practices applying the Domain Driven Design (DDD), the Onion Architecture, Command Query Responsibility Segregation (CQRS), etc. and more importantly Common sense 😉 to keep the project simple and pragmatic.

Case Study

We may come from different experiences and backgrounds but all developers are familiar with bug tracking systems, a necessary evil of the contemporary software development. We know the domain, the ubiquitous language (”backlog”, ”sprint”, ”project”, etc.), how such systems get consumed by the end-user. Eventually we did not have much of a choice on what our intended application would do 🙂 and here we go – our project is one more solution for a well-known problem and it’s called ”Yet Another Bug Tracker“.

The source code is available at

Once again, the solution is not meant to be commercially viable, but rather be a convenient example helping the developers in building other enterprise solutions.

Domain Model

The bug tracker domain is quite popular among the DDD gurus and well-covered by Vaughn Vernon in his books. I will conveniently refer to his book ”Domain-Driven Design Distilled” for explanation of the domain model (structuring entities and aggregates).

We start off with a simple model (like on the diagram below) and will add more entities and aggregates later. It will be all about the Backlog Item aggregate with various related entities like Project, User/Team, Sprint etc.

DDD diagram

Architecture / Software design

The architecture of the YABT project is based on the Onion Architecture to avoid known structural pitfalls, such as undesired dependencies between layers and contamination of the externally facing layer (e.g. API or UI) with business logic.

While the YABT has some deviations from the classic Onion Architecture, it definitely follows the key tenets:

  • The application is built around an independent object model.
  • Inner layers define interfaces. Outer layers implement interfaces.
  • Direction of coupling is toward the center.
  • All application core code can be compiled and run separate from infrastructure

Our diagram has some resemblance with the classic Onion diagram:

Onion architecture

Sure thing, the YABT follows the SOLID principles. It’s by default.

Planned articles

  • NoSQL Data Model through the DDD prism“.

    Leveraging the Domain-driven Design (DDD) to define the problem area (Bounded context) of the project. Designing a potential relational model and the NoSQL model utilised in the YABT (with aggregates, entities, value objects, etc.).

  • Hidden side of document ID’s in RavenDB“.

    A RavenDB document identifier is a string that is globally unique in the scope of the database. What document ID generation strategy to choose? The article covers pros and cons of some strategies and ways to mitigate the cons.

  • Power of Dynamic fields for indexing dictionaries and nested collections in RavenDB“.

    Leveraging the Dynamic fields in the index, we’ll fetch backlog items to build ”My recent tickets” for the current user (ones modified by the user fetching the right timestamp in the history of modifications) and manage a collection of custom fields with searching capability.

  • One-to-many, many-to-many entity relationships in NoSQL

    How ’one-to-many’ and ’many-to-many’ relationships can be implemented in RavenDB. Consider examples of tickets referring users (have just ID or a reference object), implications of having comments as an entity in the Ticket aggregate, etc.

  • Multi-tenanted databases with RavenDB

    Managing multiple clients in one DB and multiple projects for one client.

  • Building SQL-NoSQL integration SQL ETL Generic“.

    Leveraging SQL ETL for integration with SQL databases to use traditional OLAP/OLTP tools or mitigate skepticism of architects on using a NoSQL DB.

  • Full-text search. Abandon ElasticSearch, embrace RavenDB

    Finding text in the summary, comments and other fields of backlog items. Will talk about difficulties of searching in user names. Will leverage analysers for different types of fields.

  • Graph queries in RavenDB

    Issues can be linked to each other (marked as ’related’, ’blocker’, ’caused by’, etc.). Using Graph Querying we’ll show all linked tickets, developers assigned to a chain of tickets, etc.

  • Quick Aggregation via Faceted Search

    Calculate estimates on backlog items with using Faceted Search. Show how many backlog items and total of points/hours are in the sprint (remains in the current, total in the next), backlog items marked as ’Done’ by the assigned user, counts per each tag/area, etc.

  • Dive in Map-reduce indexes of RavenDB

    Using Map-Reduce Index we’ll build recent user’s activity – backlog items edited by the user with details of the performed action.

Check out the source code of the YABT. Let us know what you think. Stay tuned!