DEV Community: Julia Shevchenko

How Ubiquitous Language Can Solve Your Communication Issues

Julia Shevchenko — Wed, 01 Apr 2026 07:35:18 +0000

When someone asks me what Domain-driven design is for, I always tell a story that happened to me once.

I joined a new project and had long onboarding meetings where I was told what was already in place and what should be done. The language of communication was English. I am not a native English speaker, but by that time, I hadn't had any issues in communication. I was trying hard to understand the current system infrastructure, architecture, and future requirements. There was no documentation, and the only source of truth was verbal discussion. Soon, I've noticed something unclear.

First, I've discovered a tenant as a part of a multitenancy setup - a customer who owns a dedicated instance of software. Then another meaning of "tenant" emerged: a person or company who rents an apartment. Both, also, could occasionally be called users, which confused me even more. When I finally understood what was happening and pointed out that we have this ambiguous naming, the person I was speaking to told me that in his native language, they have different words for these things, but English happens to be less descriptive. As a result, we agreed to use different words and be specific to what we're talking about. It simplified my life a lot while onboarding new members on this project some time later.

And similar situations happened to me many more times. And I see that it is continuing to happen among many other teams.

Domain-driven design does not start with the code. It starts with team cooperation in discussing and agreeing to use a common project language, widely known as the ubiquitous language.

How should I start?

Follow this (not so easy as it looks) two-step plan to start with Domain-driven design:
Step 1 - Within the project team, agree on all terms you have and start using them correctly. Team members could encourage and support each other when adopting new terminology.
Step 2 - Continue using it! The project will grow and evolve, and the language must keep up with it.

If you wonder if following any DDD principles is worth your time in the era of LLM-agents writing code for you, check my article to see how you can benefit from DDD even more.

However, DDD could also benefit from adopting cutting-edge technologies. Let's see how it can help us.

The source of truth

Having a source of truth is a solid helper in any discussion. Set up a glossary with all the terminology that is domain-specific or project-specific. Start small - put the most used words and phrases. I would also recommend putting the abbreviation there if there are any, it will help a lot! It should not be fancy, it could even be a text file but shared with the whole team inside some cloud. Each team member could add new things, but editing already existing ones should require the team's approval, so everyone is aware that something has changed.

Nowadays, you can start by asking an LLM to create a first version of a glossary and propose the meaning of each term, so the team doesn't need to start from scratch. It can even group and format it nicely and prepare the format for any tool you'd like to use.

The source of truth becomes unreliable

Here comes the hardest part.

Project evolves, new functionality appears, new customers start using their own terminology, new team members bring new abbreviations, and the source of truth becomes unreliable, because it was updated 2 years ago by the person who is not even part of the team anymore.

Just as the project development process is a continuous process, the maintenance of the ubiquitous language should also be continuous. It is the only way to benefit from it, from the time you've already dedicated to its development and adoption.

And here, modern technologies could also help. You can create a recurring task to review the glossary against the codebase, tickets, documentation, and other relevant sources to see if anything new has appeared or been changed. Then, it could be a quick 5-minute discussion within the team if everyone agrees with that. It could also be done in async mode by some vote tool.

Just imagine how much easier onboarding a project would be with a documented glossary.

Came after a 2-week vacation and can't understand what the new abbreviation means? Check the glossary!

Have noticed some ambiguity in the code - check the glossary to know how it should be refactored.

Domain-driven design is not just for software developers, it is for the entire team to be able to communicate efficiently.

The article cover is Aleksandra Ekster's artwork "Venice".

Is DDD still relevant in the vibe-coding era?

Julia Shevchenko — Wed, 25 Mar 2026 19:05:48 +0000

It is not possible to deny that a massive shift has happened. It's hard to say the exact percentage of code that is now generated by LLMs. But what is obvious - this number rapidly grows. A lot of people are questioning the role of a software engineer and whether such a profession will exist in a couple of years.

However, LLMs are not working autonomously. They need someone to orchestrate them, providing a specification and validating an outcome. The more precise the specification is, the better the result you can expect. Basically, this rule applies to any development process.

Moreover, an LLM produces much more suitable code when given an example. The example could be a short code snippet, but it would be much better if it followed the project's codebase style and approaches.

Finally, the generated code should be reviewed and tested carefully.

Evolution of Communication

Language is a way to communicate with other people. And sometimes it is not an easy task. It happens to be quite difficult to express thoughts or to understand other people's ideas. Language allows one to express something in an endless number of different ways. Speaking is not deterministic, but humans handle that complexity in most cases.

Computers, on the other hand, understand only 0 and 1. The problem is - people don't.

Programming languages were designed to fill this communication gap. They have strict rules for expressing what needs to be done so it can be clearly translated into what the computer understands. The program will do exactly what you tell it to do via programming language.

But what happened recently is that we can now communicate with coding agents in any language, and the agent translates it to the programming language of our choice. And here comes a problem - speaking is too ambiguous. And if the code base is also too ambiguous, no agent will be able to generate proper and reliable code that fits your needs, especially business logic.

You tell it to make a change to tenant management, but there are places in code where it is called client.

You tell it to add some functionality for a buyer, but it is also called a consumer, purchaser, and, again, client.

You tell it to add a new entity - client, because this is how it was called in meetings, but there are already plenty of things named as client in the code.

And each time you have to explain what is what, and you may still miss some tiny detail.

Of course, the good-to-go approach is to tell the agent to collect knowledge about the domain. But it is hard to aggregate the domain knowledge if the domain is not clearly defined.

Meet your new colleague

In addition to overcoming difficulties in communication between teams, you now need to overcome difficulties in communication with AI Agents. To reduce the number of hallucinations, you need to provide it with clear instructions and a summary of project knowledge so it can rely on them instead of repeating the same research every time. You need to be precise with terminology and in describing the results you want to achieve. It is very similar to onboarding a new colleague to the project.

What is Domain-Driven Design?

Domain-Driven Design - is a concept of having code base that reflects the business logic. It unites two worlds - technical and product commands, so they can understand each other better and work together more efficiently. I often see that Domain-Driven Design is defined as a set of patterns. However, patterns are only tools to achieve the final goal, and it is not mandatory to follow all of them.

From an engineering perspective, use cases reflect what's going on in real life, and the code becomes more than just a set of random get/set calls. Why is it a good thing? Any request for a change to business logic can be easily translated into an existing code base. The question, "How does this feature work?", does not require a week of investigation. Of course, real life is much more complicated, and such a state cannot be reached from the decision to apply DDD to the project from day one. It is the process of evolution to become business-centric, not framework-centric or infrastructure-centric. It requires hard work, with both engineering and product teams involved, to define and shape the domain.

Is it still relevant?

So, what advantages does Domain-driven design provide for AI-first development?

Writing in DDD-style makes code more readable -> review process will become easier and faster;
The domain layer literally repeats domain logic -> easy to notice if some use case is missing or doesn't do what is expected because the logic isn't scattered throughout the project;
Domain-centric code is easy to cover with unit tests that check domain logic, not just getters and setters -> code becomes easier to maintain and extend; easy to notice that something is broken;
Ubiquitous language makes the communication easier not only with humans, but also with LLMs -> less confusion means less hallucinations;
Bounded contexts could force making smaller changes -> change will be applied to a context, not affecting the whole project with unpredictable consequences;

Domain-driven Design solves the same problem as before - decreases ambiguity and brings clarity to the development process, but now with the new party involved. Product and engineering teams, along with AI-agents, share the same knowledge.

Would I still apply DDD to a project? Definitely.

It may seem like such concepts are now outdated. Why bother with such things when an AI agent can write code for us, fix bugs, and answer questions about the product? But all of these rely on an input context. When the input becomes messy, the quality of the outcome drops drastically. Same as with simple old manual engineering - you must keep the bar high to maintain high-quality results.

The article cover is a fragment of Oleksandr Bohomazov's artwork "Sawyers".

How to check if AutoMapper misses any mapping

Julia Shevchenko — Thu, 29 Jan 2026 15:30:00 +0000

I am a hater of AutoMapper. I don't think it is really beneficial to delegate mapping to it, because over time, it becomes a mapping hell where you are trying to identify which properties haven't been mapped and where and why. You would never be in such a situation if you just manually map one type to another. Yes, it is boring. But it is stable. After all, you can speed it up with Copilot or any other tool.

But if you got trapped in AutoMapper frustration, I'm here to cover your back.
There is a very fast and easy way to check if any type maps are missing. Add this to your startup script, and it will tell you during startup if there are any unmapped properties. This will throw an exception if there are any issues, preventing the application from running.

var app = builder.Build();

using (var scope = app.Services.CreateScope())
{
    var mapper = scope.ServiceProvider.GetRequiredService<IMapper>();
    mapper.ConfigurationProvider.AssertConfigurationIsValid();
}

Example output

Unhandled exception. 

AutoMapper.AutoMapperConfigurationException: Unmapped members were found.

Review the types and members below. Add a custom mapping expression,
ignore, add a custom resolver, or modify the source/destination type 

For no matching constructor, add a no-arg ctor, add optional arguments, 
or map all of the constructor parameters 

=============================================
CustomerDto -> CreateCustomerCommand (Destination member list) 

SampleApp.Application.Dtos.CustomerDto -> 

SampleApp.Application.Commands.Customers.CreateCustomerCommand (Destination member list)

Unmapped properties: 
OrganizationId 
=============================================

CustomerDto -> UpdateCustomerCommand (Destination member list) 

SampleApp.Application.Dtos.CustomerDto -> 

SampleApp.Application.Commands.Customers.UpdateCustomerCommand (Destination member list)

Unmapped properties: 
OrganizationId 
CustomerId 
=============================================

🗺️ Enjoy your coding!

How to Inject Service from DI Container to Marten Async Projection

Julia Shevchenko — Thu, 09 Oct 2025 15:18:51 +0000

Recently, I had a need to inject a service directly from the DI Container to the Marten Async projection. The issue is that Marten async projections are run in separate scopes, so they cannot reach services from other scopes.
It appeared to be tricky, and I couldn't find any information in the documentation on how to overcome it.

Marten async projections VS DI

Marten runs async projections in the background daemon.
These projections are run out of any HTTP request or message handler scope, so it's not possible to inject scoped services directly.

ILogger, for example, is usually registered as a singleton, so Marten allows it to be injected into async projections.

Typical Configuration

This is how async projection configuration usually looks:

builder.Services.AddMarten(storeOptions => {})
  .AddProjectionWithServices<MyProjection>(
      ProjectionLifecycle.Async,
      ServiceLifetime.Scoped
  );

Also, it could be like this:

builder.Services.AddMarten(storeOptions => {
  storeOptions.Projections.Add<TripProjectionWithCustomName>(ProjectionLifecycle.Async);
})

This lambda runs at container build time, not inside a request scope, so there is no direct access to the DI container.

The Workaround

The possible way to solve it is to inject the ServiceProvider to use it as a Service Locator and get the service directly from it. It's not good practice, though.
I was lucky to find this GitHub Issue, which gave me a clue how to proceed with it.
There is an overload of AddMarten that injects the serviceProvider.
Here is what you need: create an instance of your projection, pass IServiceProvider or any other service as a parameter, and add this instance to the Marten with Projections.Add. To be able to get the ServiceProvider - return the StoreOptions.

builder.Services.AddMarten(serviceProvider =>
{
  var options = new StoreOptions();

  MyProjection mytProjection = new(
      serviceProvider.GetRequiredService<ILogger<MytProjection>>(), 
      serviceProvider.GetRequiredService<IServiceProvider>());
  options.Projections.Add(mytProjection, ProjectionLifecycle.Async);

  return options;
};

When you return options, you’re handing your fully configured StoreOptions back to Marten so it can build the document store. Marten calls this lambda after the service container is created, so the serviceProvider argument is already a fully built root container.

Hope this article was helpful and saved you some time!

Have you ever worked with Event Sourcing and the Marten framework in particular? How do you like this experience?

Auto-generated IDs VS Manually created: which approach to chose?

Julia Shevchenko — Mon, 22 Sep 2025 07:19:21 +0000

Creating incremented auto-generated integer IDs on a database level was a default approach for a long time. It was (is?) very popular for a reason.

Advantages of generated IDs includes:

No need to manage IDs manually in code + database guarantees uniqueness;
Integers perform fast DB-level for joins, comparisons, indexing, and take less storage size;
Natural Ordering - Sequential IDs help clustered indexes, reduce fragmentation.

However, with modern software architecture evolving, this approach may not be the best option.

Let's compare this approach and the approach with manually creating IDs by example. It is simplified but reflects a common business case without diving into details.

This article shows examples in C# and EF Core, but the same approach can be used for any language and ORM that implements the Unit of Work pattern.

Example case description

Let's imagine there are three independent microservices or modules: OrderService, PaymentService, and ShippingService. Each module has its own database.

Order service saves an Order with all its information, including OrderItems. Payment service is not interested in Order Details, it tracks if the Order was paid or not. Shipping service wants to have its own Order, but it should only contain shipment information.

Orders should be easily synced between services, so that the most recent information about the order is available in whichever service and it is easy to get information about the order from other services if needed. Payment Service has OrderId and it should be the same for Orders in all services.

Using auto-generated IDs

The following code shows what it looks like with the IDs generated on the DB level.

Disclaimer: I'm advocating for initializing domain entities through constructors, but for the articles, it is more readable to do it with object initializers.

public async Task<int> Handle(CreateOrderCommand request, CancellationToken ct)
{
    var order = new Order
    {
        TotalPrice = request.TotalPrice,
        OrderItems = request.Items.Select(i => new OrderItem
        {
            ProductId = i.ProductId,
            Quantity = i.Quantity
        }).ToList(),
        OrderedAt = DateTime.Now()        
    };

    _dbContext.Orders.Add(order);
    await _dbContext.SaveChangesAsync(ct);

    var paymentEvent = new OrderCreatedForPayment
    {
        OrderId = order.Id,
        TotalPrice = order.TotalPrice
    };

    var shippingEvent = new OrderCreatedForShipping
    {
        OrderId = order.Id
    };

    await _messageBus.PublishAsync(paymentEvent, ct);
    await _messageBus.PublishAsync(shippingEvent, ct);

    return order.Id;
}

This example looks not that bad, however, it has potential issues:

Order cannot be saved in the same transaction with events to apply Outbox pattern because Order Id will be available only after SaveChangesAsync() is called;
There is no guarantee that Order in other services, Shipping Service in particular, will be created with the same ID. And this point is crucial;
Entities rely on the infrastructure.

The same object should be identified the same way across different services or modules. Of course, it is possible to solve this by adding a separate column OrderId along with the database ID. But it adds complexity, makes it harder to maintain and may introduce errors if identifiers are misused.

Using manually created IDs (Guid)

Let's see how we can improve this case by manually creating IDs.
In C# the common type for IDs will be Guid. In SQL, it will be translated into type UUID v4. Important: to generate a new random Giud, you need to call a static Guid.NewGuid(), not create a class instance.

public async Task<Guid> Handle(CreateOrderCommand request, CancellationToken ct)
{
    var orderId = Guid.NewGuid();

    var order = new Order
    {
        Id = orderId,
        TotalPrice = request.TotalPrice,
        OrderItems = request.Items.Select(i => new OrderItem
        {
            ProductId = i.ProductId,
            Quantity = i.Quantity
        }).ToList(),
        OrderedAt = DateTime.Now()         
    };

    _dbContext.Orders.Add(order);

    var paymentEvent = new OrderCreatedForPayment
    {
        OrderId = orderId,
        TotalPrice = order.TotalPrice
    };

    var shippingEvent = new OrderCreatedForShipping
    {
        OrderId = orderId
    };

    _dbContext.OutboxMessages.Add(new OutboxMessage
    {
        Id = Guid.NewGuid(),
        Type = nameof(OrderCreatedForPayment),
        Payload = JsonSerializer.Serialize(paymentEvent),
        OccurredOnUtc = DateTime.UtcNow
    });

    _dbContext.OutboxMessages.Add(new OutboxMessage
    {
        Id = Guid.NewGuid(),
        Type = nameof(OrderCreatedForShipping),
        Payload = JsonSerializer.Serialize(shippingEvent),
        OccurredOnUtc = DateTime.UtcNow
    });

    await _dbContext.SaveChangesAsync(ct);

    return orderId;
}

Advantages of this approach are:

Order is created in the same transaction as corresponding events ensuring data integrity;
Only single DB connection was opened for this piece of code;
Entity is untied from the Infrastructure;
Order will be created with the same identifier across all microservices, modules or, even, systems. This means data can be easily synced or merged, if needed.
We are fully in charge of how the identifier is generated. We could use any of the UUIDs or even compose it with some additional information. For example, if we want natural ordering and timestamp-based identifier, we may use UUIDv7;
It is easier to write tests, because there is no need to save the entity to access its ID. This may sound not important, however it's crusial that the code is easily testable which leads to better tests quality and therefore less problems in the future.

Note: for this implementation, you will also need background service to read OutboxMessages and publish them to the message broker.

EF Core Configuration

By default, EF Core generates values for the defined identifiers depending on its type - integers or GUID.
Here is how to configure EF Core to not generate IDs using Fluent API. This should be a part of DbContext:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Order>()
        .Property(o => o.Id)
        .ValueGeneratedNever();
}

What about sequences?

There is a workaround on how to get next value for autogenerated IDs. You can say ORM, in our case EF Core, to use sequence as the default ID generator for an entity.

A sequence is a database object that generates a sequence of numbers (1, 2, 3, …) independent of any table. When you call it to get the next value, it reserves the value so it could not be used in another transaction.
The next value in code can be with a raw SQL call (which is not very elegant).

var nextId = await context.Database
    .SqlQueryRaw<int>("SELECT NEXT VALUE FOR MySequence")
    .FirstAsync();

Could it solve all our concerns? Not really.

Imagine that there is a need to create new Service that also produces Order, for example, Subscription service. Each service has its own database. It means that there is a very high chance to have Orders with same IDs in different services.

Yes, this may never happen, but business requirements change rapidly and are not always predictable.

Remember, Entity should be unique across the whole system.

Conclusion

Shifting responsibility to the database to manage ID values leads to:

No ability to provide data consistency between services or modules;
Concurrency issues when two or more threads try to create a row with the same id;
Difficulties with synchronizing database data;

These are crucial for microservice or event-driven architectures and could be solved by utilizing manual IDs creation.

It is worth mentioning that integer IDs are claimed to be faster and take less disc space. However, nowadays databases are stored in the cloud and have significantly more performance capabilities than before. For massive tables, smaller indexes may help, but for normal-sized cloud apps, the difference is often negligible. Additionally, there are UUIDs which are timestamp based, so could cover natural ordering needs.

Of course, every decision is a trade-off. The manual creation of IDs is not the silver bullet. There is a chance of collision (which is nearly zero), they are less readable and take more space than integer values.
Every project is special and there is no single right way to build it.

However, for most modern applications, especially those with an emphasis on domain logic, it is a great approach, which will save you a lot of time and prevent unexpected errors.

Thank you for reading!

Feel free to share in the comments, which approach do you prefer and why?

TODO or not TODO / Stop spamming the code with useless comments

Julia Shevchenko — Mon, 25 Aug 2025 16:06:50 +0000

It has been proven that the best way to solve a complex task is to divide it into smaller tasks. Some people create a to-do list in a notebook, some draw a diagram, others prefer to keep the plan in their minds. And, of course, many of the engineers use TODO comments in their code, not to forget something.

What may go wrong? One //TODO: here and one //TODO: there. But as a result - no one ever takes care of those comments. Everyone is afraid of touching them: what if it is something important? There is always an endless list of tasks in the task manager, and there is no task to treat the abandoned TODOs. If you haven't observed something like that, are you sure? (Lucky you!)

"What is she talking about?" - you may think, as these types of comments are extremely popular and an absolutely normal thing.

I will share some examples with you.

// TODO: log result

It will take 15 seconds to write a log.

// TODO: add test

It will take 5-10 minutes to write a test.

// TODO: verify result

It is your responsibility to verify if it is working, and it also does not take that much time. Do it now, not later (which means never).

//TODO: fix

You have found a bug and just left the comment, so no one has an idea that something is broken? Please, go and create a ticket with the problem description. If the problem is not on the board, it doesn't exist.

//TODO:  check later

Check what? When? By whom? Why? Why not handle it now when you're in the context?

By leaving such comments, you shift responsibility from you to another person who will find this comment. Besides, you provide absolutely no context.

How to use TODOs properly?

If you want to remind yourself about something you don't want to forget, or you are waiting for some details while working on the task, it is completely fine to use the TODO comments. It's even a good idea, because human memory is not very reliable. Just make sure to take care of these comments before you merge. It should be living within the scope of the current piece of work.

If it's a 5-minutes-job, just do it. If it's a bug, create a ticket. Need some additional information, ask for it. But do not postpone a problem for the future.

A hack from me: write preconized todos, like todo-julia, and create a filter for the IDE to show your specific todos. It helps to filter your comments from others.

Another scenario is when you want to warn your teammates or your future self about something critical and unobvious that needs to be implemented on the next iteration of the task, and cannot be implemented now because of some circumstances. And you feel the need to have it not only in the ticket, but also in the code to be more specific about something tricky. If the comment is meaningful and concise, it is fine. But it should not last forever. The purpose of the comment should be to help, to guide, not to confuse.

TODO or not TODO - is your personal choice. A perfect code base does not exist, but you can contribute to making it cleaner.

Health Check setup for .NET application

Julia Shevchenko — Fri, 20 Jun 2025 11:42:38 +0000

What is a Health Check?

A Health Check is an indicator of service availability. For web applications, it's an endpoint that returns the current state of the application - usually, it could be Healthy, Degraded, or Unhealthy. Health checks can be configured for any type of service, such as a database or a message broker, or can be set to track any crucial part of the application.
It is frequently used in CD pipelines to observe if the service has any issues and restart it if needed.

Basic Health Check configuration

To add a basic health check, you need to do two things:

Register a health check in the DI: builder.Services.AddHealthChecks();
Add a middleware and set a path to the health check endpoint: app.UseHealthChecks("/health")

That's it - if your application is able to start, then /health endpoint will return 200 OK and a plain text response with the string "Healthy". Everything else is considered Unhealthy.
However, with this basic configuration, it won't track any major problems. For example, if the database becomes unavailable, the health check will still indicate a Healthy state.

Tuning Health Checks

To define custom logic for health check - just implement IHealthCheck interface and then register the implemented health check like this:

builder.Services.AddHealthChecks()
    .AddCheck<CustomeHealthCheck>("Sample");

However, there are plenty of ready-to-use extensions to cover most of your needs - database management systems, message brokers, check for system info like disk storage, network status, and even a ui tool to observe all this information.

The example usage:

builder.Services.AddHealthChecks()
    .AddSqlServer(
        connectionString: "your-connection-string",
        healthQuery: "SELECT 1;",
        name: "sqlserver",
        failureStatus: HealthStatus.Unhealthy);

Practical usage

Having a health check but not tracking its status doesn't make sense.
The possible options for it are:

UI dashboard, which will be accessible by some url inside your application
Kubernetes / Docker Health Probes, which allow to configure automatic recovery
Add as a metric to Application Insights / Grafana / other tools

Adding a health check will help keep your service available and prevent you from missing any issues.

Thanks for reading,
Wishing you successful deployments and enjoy your coding!

Parallel Queries in EF Core with PostgreSQL: Why It Fails and How to Fix It

Julia Shevchenko — Tue, 15 Apr 2025 17:19:43 +0000

You may have faced an interesting error trying to run queries in parallel with EF Core and Postgres: "A command is already in progress" which isn't very specific but refers to parallel execution failure.

This piece of code represents an intention of parallel query execution:

var city = db.Cities.ExecuteDeleteAsync();
var forecasts = db.WeatherForecasts.ExecuteDeleteAsync();

await Task.WhenAll(city, forecasts);

Seems that it should work, so what's wrong?

Let's get a little bit into the details of what's going on here.

ExecuteDeleteAsync() runs the SQL query in DB immediately, so there is no need to call SaveChangesAsync(). Also, EF Core doesn't track any changes as entities are not loaded into memory.

Task.WhenAll() allows tasks to be awaited concurrently. When dealing with I/O-bound operations, such as database interactions, they are expected to be parallelized, as in our case.

Please note that city and forecast entities are not connected with a foreign key. It looks like they should be, however, for testing purposes, I intentionally avoid that. If they are connected with a foreign key and have a CASCADE restriction, then this call will work because forecasts will be deleted along with the cities.

What have we missed?

It turned out that Postgres doesn't support parallel query execution within the same connection, unlike the SQL Server.

💡Tip: The support of parallel query execution in the SQL Server is turned off by default, but it's possible to enable it with MultipleActiveResultSets=True.
But be careful and consider the potential risks. Ask yourself, are you sure your project needs it?
With such configuration, the code above will work.

Is there anything you could do?

Yes, you can run queries with separate db contexts, meaning queries will run on different connections. However, a more general approach is to run queries sequentially.

await db.Cities.ExecuteDeleteAsync();
await db.WeatherForecasts.ExecuteDeleteAsync();

Should you get upset because of it?

Definitely not.

❌ Parallel query execution has underlying concurrency limitations, which could lead to deadlocks or timeouts
✔️ Queries from separate connections will be executed in parallel at the I/O level, and the DB runs them in parallel, too.

How to Parse Environment Variables into DTO in .NET: AWS S3 Bucket Example

Julia Shevchenko — Wed, 02 Apr 2025 09:23:26 +0000

Working with objects is always better than with "magical" strings. Having multiple configuration strings for some services can be uncomfortable to work with. Also, it increases the number of parameters to pass to a service. If you add one more parameter to the configuration section, you will need to manually retrieve it from the configuration and pass it to the service, where it will be used.

Treating configuration settings as a DTO class will make your code more readable.

Parse config into DTO class

As an example, I have a configuration for an AWS S3 bucket in appsettings.json

"AwsS3": {
  "AccessKey": "your-access-key",
  "SecretKey": "your-secret-key",
  "BucketName": "your-bucket-name",
  "Region": "us-east-1"
},

Let's create a DTO class for it:

public class AwsS3Settings
{
    public string AccessKey { get; set; } = string.Empty;
    public string SecretKey { get; set; } = string.Empty;
    public string BucketName { get; set; } = string.Empty;
    public string Region { get; set; } = string.Empty;
}

Now, it's time to configure the dependency injection container to store our configuration. This code reads the configuration section, maps it to the AwsS3Settings class, wraps it with IOptions<T>, and adds it to the container as an IOptions<AwsS3Settings>.

builder.Services.Configure<AwsS3Settings(builder.Configuration.GetSection("AwsS3"));

It means now it is possible to inject it in some service like this:

public class AwsS3Saver(IOptions<AwsS3Settings> settings

If you want to inject your configuration DTO directly, without IOptions cover, you can register it as a Singleton in the container.

builder.Services.AddSingleton(sp => sp.GetRequiredService<IOptions<AwsS3Settings>>().Value);

Then, you will be able to inject the DTO directly to any service:

public class AwsS3Saver(AwsS3Settings settings)

Parse config into Record

Usually, such data is treated using a record, not a plain class. However, the record cannot be used to map configurations into it in the same way. If you try, you will get an exception: System.MissingMethodException: Cannot dynamically create an instance of type 'EnvToDtoDemo.Settings.AwsS3SettingsRecord'. Reason: No parameterless constructor defined.
The reason behind that is in IOptions<T>, which requires parameterless constructor and set; for a public properties.
Records use constructors with parameters and use them to initialize properties, so they can be set only during initialization, which makes them immutable.

However, you still can use records for parsing environment variables, but with a slightly different approach. Use Get extension method to map configuration to a strongly typed object, which is our AwsS3SettingsRecord. After that, add it to the container.

public record AwsS3SettingsRecord(string AccessKey, string SecretKey, string BucketName, string Region);

var awsS3SettingsRecord = builder.Configuration.GetSection("AwsS3").Get<AwsS3SettingsRecord>()
                    ?? throw new InvalidOperationException("AwsS3 settings are missing!");

builder.Services.AddSingleton(awsS3SettingsRecord);

That's it! Now you can inject the record with configuration where needed.

🖖 Enjoy your coding!

How to make an API call in the middle of an OpenAI conversation

Julia Shevchenko — Thu, 27 Feb 2025 14:47:45 +0000

While AI integrations become more and more desirable features, the need to perform additional functionality, for example an API call, in the middle of the conversations is the biggest concern for developers. Even though it is possible to provide AI assistants with clear instructions, they sometimes struggle to follow them. The most problematic are if/else conditions.

For demonstration purposes, I've created a console application that will simulate a chat with OpenAI via completion API. So, everything is put inside the background Worker class. We will use Azure.AI.OpenAI package to interact with the API.

Step 0. The basics

Completions API doesn't store the state, so we need to pass the chat history with every call. Chat history should consist of ChatMessage type.
There are several chat ChatMessage types:

SystemChatMessage (system) - use to provide system instructions that will be considered by OpenAI but won't be visible to the user;
UserChatMessage (user) - contains messages from the user;
AssistantChatMessage (assistant) - contains messages from OpenAI;
ToolChatMessage (tool) - use to provide result of the tool (in our case function) call.

ChatTool - is a concept of additional chat functionality, in our case, a function. So, every function is a ChatTool.

Step 1. Starting a conversation

First of all, we need to have system instructions to describe OpenAI's role in this conversation. Here, we can also tell OpenAI that we want to execute some function after specific user actions.

In this example, I want it to be an assistant in a bookstore, and when the user picks up a book - execute a function that will call our API to get book information, check if there are any deals, and tell the user if there are any.

So, when the user says, "I want to buy this book", we will make a call to our bookstore API, check if there are any, and send SystemChatMessage with new instructions. Doing the deal check on our backend will also help to avoid OpenAI misbehavior with if/else conditions.

Inside such function calls, we can do whatever we need: call an API, do some calculations, send emails, etc.

In the diagram, I show the part of the simplified flow from the user message that indicates a desire to buy a book to the new instruction for OpenAI.

Let's now move on to the implementation.

We will store message history in the messagesHistory property of type List<ChatMessage>.
ExecuteAsync is an entry point for our background worker. So, we are waiting for the user to type anything, then save the message and continue our conversation.

protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
    var systemInstructions = 
        $"""
            You are an assistant in a bookstore. Ask user about their interests and genres they like 
            or what they would like to read about and based on the answer suggest 5 books.
            After suggestion ask if user wants to buy any of the books. If user wants to buy a book,
            call {FindBookFunctionName} with the book name and author.
        """;

    _messagesHistory.Add(new SystemChatMessage(systemInstructions));

    Console.WriteLine("Assistant: Hello! How can I help?");

    while (!stoppingToken.IsCancellationRequested)
    {
        Console.Write("User: ");

        var question = Console.ReadLine() ?? throw new InvalidOperationException();
        _messagesHistory.Add(new UserChatMessage(question));

        await ContinueConversation();
    }
}

Calling a function without any context would be useless. We need to have information about the book that user has chosen: name and author. For this, we need to define which fields we are expecting to receive from OpenAI. It can be done as the following:

private static List<ChatTool> GetFunctionsDefinitions()
{
    return
    [
        ChatTool.CreateFunctionTool(
            functionName: FindBookFunctionName,
            functionDescription: "Returns a list of books suggested to a user.",
            functionParameters: BinaryData.FromString(JsonSerializer.Serialize(new
                {
                    type = "object",
                    properties = new
                    {
                        name = new { type = "string", description = "Book name" },
                        author = new { type = "string", description = "Book author" },
                    },
                    additionalProperties = false,
                    required = new[] { "name", "author" }
                }
        ))),
    ];
}

Step 2. Continue Conversation

To continue conversation, we will always send message history to the OpenAI API including functions definition if there are any.

private async Task<ChatCompletion> SendMessages(ChatMessage[] messages)
{
    var chatClient = openAiClient.GetChatClient("gpt-4o-mini");

    ChatCompletionOptions options = new();
    foreach (var tool in GetFunctionsDefinitions())
    {
        options.Tools.Add(tool);
    }

    return await chatClient.CompleteChatAsync(messages, options);
}

The response will always be a ChatCompletion object with FinishReason which could be one of the following: Stop, ToolCalls, Length, ContentFilter and FunctionCall.
We are interested in the first two. For simplification, others are omitted in this example.

Stop indicates that there is an ordinary response from OpenAI with some text. We need to store it as an AssistantChatMessage.
ToolCalls means that OpenAI identified that some Tool is required to be executed. It is our responsibility to execute it. The text from the response should be also stored in AssistantChatMessage. And, in addition, each tool call result should be saved as ToolChatMessage. After ToolChatMessage and SystemChatMessage are sent, we need to ContinueConversation, so OpenAI can react to new prompts.

In this example, we will execute tool calls in ExecuteToolCall method.

private async Task ContinueConversation()
{
    var chatCompletion = await SendMessages(_messagesHistory.ToArray());

    switch (chatCompletion.FinishReason)
    {
        case ChatFinishReason.Stop:
            _messagesHistory.Add(new AssistantChatMessage(chatCompletion.Content[0].Text));
            Console.WriteLine($"{chatCompletion.Role}: {chatCompletion.Content[0].Text}");
            break;
        case ChatFinishReason.ToolCalls:
        {
            _messagesHistory.Add(new AssistantChatMessage(chatCompletion.ToolCalls));

            foreach (var toolCall in chatCompletion.ToolCalls)
            {
                var response = await ExecuteToolCall(toolCall);
                _messagesHistory.Add(new ToolChatMessage(toolCall.Id, JsonSerializer.Serialize(response)));

                if (response.SystemMessage is not null)
                {
                    _messagesHistory.Add(new SystemChatMessage(response.SystemMessage));
                }
            }

            await ContinueConversation();
            break;
        }
        default:
            throw new ArgumentOutOfRangeException();
    }

Step 3. Execute Tool Call

In ExecuteToolCall we will define how to execute each function that we may receive. In this case, it's only one, but could be any amounts.

private async Task<FunctionResponse> ExecuteToolCall(ChatToolCall toolCall)
{
    var response = toolCall.FunctionName switch
    {
        FindBookFunctionName => await GetBookDetails(toolCall),
        //other functions calls
        _ => throw new NotImplementedException()
    };

    return response;
}

Our goal here is to call our bookstore backend API to get information about the book that user wants to buy: is it available and does it have any deals that user should be notified about.

Step 4. Make an API call

GetBookDetails is the method where we can perform anything we need to extend conversation logic. It is the actual implementation of the FindBookFunctionName.

Since toolCall.FunctionArguments is binary, we can convert it into string and deserialize it to the BookRecommendation DTO.
Then, it's time to call bookstore API to get book information. After that, depending on the Deal type, add a system message.

private async Task<FunctionResponse> GetBookDetails(ChatToolCall toolCall)
{
    var bookRecommendation = JsonSerializer.Deserialize<BookRecommendation>(toolCall.FunctionArguments.ToString());
    if (bookRecommendation is null)
    {
        throw new Exception("Cannot parse the book recommendation.");
    }

    var bookDetail = await bookApiClient.GetBooks(bookRecommendation); 

    string? systemMessage = null;

    if (bookDetail.Deals.Contains(Deal.OnePlusOne))
    {
        systemMessage = "If you bye one more book, you get another one for free!";
    }
    if (bookDetail.Deals.Contains(Deal.ThirtyPercentOff))
    {
        systemMessage += "Lucky time! This book is 30% off! To apply the discount, use the code: LUCKY30";
    }
    if (bookDetail.Deals.Contains(Deal.FreeShippingIfOverFifty))
    {
        systemMessage += "If you buy books for more than 50$, you get free shipping!";
    }

    return new FunctionResponse(JsonSerializer.Serialize(bookDetail), systemMessage);
}

public record BookRecommendation(string Name, string Author);

public record BookDetail(string Name, string Author, decimal Price, List<Deal> Deals);

public enum Deal
{
    OnePlusOne,
    ThirtyPercentOff,
    FreeShippingIfOverFifty
}

public record FunctionResponse(string Content, string? SystemMessage = null);

As you can see in the second step, the system message will be sent to the OpenAI to be considered.

Let's see how the conversation will look like.

For the selected book, the deal is 1+1=2, meaning buy one more book - get another one for free. OpenAI understands the user's requests and, according to the system instructions, kindly informs the user about this possibility and even asks if he wants to use it.

I think that's a very accurate example of how businesses can benefit from OpenAI integration, especially when it is enhanced by custom functions calls.

Have you already tried OpenAI or other integrations on your projects? Do you like how it performs?

Adding another database provider (for testing) is not working in EF Core 9

Julia Shevchenko — Tue, 18 Feb 2025 14:38:50 +0000

For writing integration tests, a common approach is to change the database provider, for example, to the InMemory database. But with Ef Core 9 this approach will give you an exception: "Only a single database provider can be registered in a service provider". So, what to do if there is a need to change the database provider and even manually removing another provider doesn't help?

Searching for possible solutions, I've found this issue on the ef core repository.
It turned out that a new IDbContextOptionsConfiguration interface was introduced, which, according to the documentation, configures the options to be used by a DbContext. And if it tracks multiple database providers, the exception will be thrown.

A workaround that I found in this article is to remove the configuration from the service provider. This solution works like a charm but feels a little bit hacky. Should we manually change the configuration? However, this may still save hours for those who faced it after updating the ef core.

The current version of the documentation here is not updated yet. However, the issue is in progress, and I'm curious what the suggested solution will be.