Alex KlausDeveloper  |  Architect  |  Leader
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 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 centre.
  • All application core code can be compiled and run separately from the 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.

Check out the source code and articles under ‘YABT’ tag. Let me know what you think.