SolTechnology.Core 1.0.0

<p align="center"> <img alt="SolTechnology-logo" src="./docs/logo.png" width="200"> </p>

<h2 align="center"> SolTechnology.Core </h2>

<p align="center"> <a>Modern readable coding</a> </p>

<p align="center"> <a href="https://dotnet.microsoft.com/download/dotnet/10.0"><img src="https://img.shields.io/badge/.NET-10.0-512BD4?logo=microsoft"></a> <a href="https://www.nuget.org/packages?q=SolTechnology"> <img src="https://img.shields.io/badge/dynamic/json?url=https%3A%2F%2Fraw.githubusercontent.com%2FAdrianStrugala%2FSolTechnology.Core%2Fmaster%2Fnuget-stats.json&query=%24.totals.downloads&label=NuGet%20Downloads&logo=nuget&color=blue&suffix=%20total"> </a> <a href="https://github.com/AdrianStrugala/SolTechnology.Core/actions"><img src="https://img.shields.io/github/actions/workflow/status/AdrianStrugala/SolTechnology.Core/publishPackages.yml?branch=master&logo=github&label=build%26tests"></a> </p>

<i> <p align="center"> "Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer's intent but rather is full of crisp abstractions and straightforward lines of control." </p> <p align="right"> ~Grady Booch, author of 'Object-Oriented Analysis and Design with Applications' </p> </i>

Core Libraries

The SolTechnology.Core repository contains a set of shared libraries. This is a foundation for CQRS-driven applications using basic Azure technologies. The libraries support a modern coding approach presented in the example applications.

📦 Deprecated libraries

Testing companions

Modular NUnit .Testing packages for component / integration tests — one companion per concern, all on the shared SolTechnology.Core.Testing foundation. Reference from test projects only.

Tale Code

The idea of clean and readable code has stayed with me from the very beginning of my career. As a book lover and amateur writer, this is the most natural part of programming.
In the Tale Code approach, I am trying to summarize all the information about coding, design, automation, and configuration that I have learned over the years. The Tale Code rule is simple:

<i> <p align="center"> "Make your code a pleasure to read, like a tale." </p> <p align="right"> ~Adrian Aleksander Strugała </p> </i>

The sample application is the most common case that came to my mind. It's built of a user-facing API and a background worker responsible for fetching data and feeding the SQL database. The communication between these two is asynchronous and based on messages, as shown in the picture:

<p> <b>Code design is the main goal</b> of Tale Code. Logical flow and code structure are described in detail, and it reads like a well-written story:

public class CalculateBestPathTale(IServiceProvider serviceProvider, ILogger<CalculateBestPathTale> logger)
    : TaleHandler<CalculateBestPathQuery, CalculateBestPathContext, CalculateBestPathResult>(serviceProvider, logger),
      IQueryHandler<CalculateBestPathQuery, CalculateBestPathResult>
{
    protected override Tale<CalculateBestPathResult> Tell() =>
        Open<InitiateContext>()
            .Expect(ctx => ctx.NoOfCities > 1,
                    new NotFoundError { Message = "A route needs at least two cities." })
            .Read<DownloadRoadData>()
            .Read<FindProfitablePath>()
            .Otherwise<JustOrderCities>()      // no profitable route → just order by distance
            .Read<SolveTsp>()
            .WhenLost(error => logger.LogWarning("Best path calculation failed: {Error}", error.Message))
            .Read<FormCalculateBestPathResult>()
            .Finale(ctx => ctx.Output);
}

I have summarized the knowledge and decisions into three chapters.
Enjoy your reading! </p>

1. The Design
2. The Automation
3. The Quality

Some ending words