Building an application with .NET Core and RavenDB NoSQL Database

Yet Another Bug Tracker: Start of the Series

by Alex Klaus

Leveraging the .NET Core + RavenDB NoSQL database to build enterprise applications"

NoSQL is not hard, it's different. And to show that, RavenDB and I kick off a new series of articles dedicated to building enterprise applications 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.

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:

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 analyzers 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!

Read more articles in this series