Blog

The third in a series of articles about automated testing. This time about effective testing strategy and approaches.

The second in a series of articles about automated testing, devoted to an important quality attribute from the point of view of testable architecture - testability.

The first article in a series on automated testing discussing why you should test your software in an automated manner at all.

In previous posts in this series, I covered what a Modular Monolith is, what its architecture looks like and how this architecture can be enforced. Then I described architectural drivers for this architecture and styles of integration between modules. In this post I would like to go deeper - a level lower and describe how such architecture can be designed. We are not going to implement this architecture yet - we will focus on its technology-agnostic design.

In this post, I would just like to discuss the missing part – Integration Styles for modules in Modular Monolith architecture.

In this post I would like to discuss a frequently overlooked, though in some circumstances very important topic – concurrency handling in context of protection of the so-called Domain Invariants.

Each technology becomes obsolete after some time. It is no different with the .NET Framework - it can be safely said that after the appearance of the .NET Core platform, the old Framework is slowly disappearing. Few people write about this platform, at conferences it has not been heard for a long time in this topic. Nobody starts a project in this technology. Only the .NET Core everywhere... except for a beloved legacy systems.

In previous posts we discussed what is the architecture of Modular Monolith and architectural drivers that can affect its choice. In this post, I would like to focus on ways to enforce chosen architecture.

In the first post about the architecture of Modular Monolith I focused on the definition of this architecture and the description of modularity. In this post I would like to discuss some of the most popular, in my opinion, Architectural Drivers which can lead to either a Modular Monolith or Microservices architecture.

Many years have passed since the rise of the popularity of microservice architecture and it is still one of the main topics discussed in the context of the system architecture. The popularity of cloud solutions, containerization and advanced tools supporting the development and maintenance of distributed systems (such as Kubernetes) is even more conducive to this phenomenon.

There is a lot of talk about clean code and architecture nowadays. There is more and more talk about how to achieve it. The rules described by Robert C. Martin are universal and in my opinion, we can use them in various other contexts. In this post I would like to refer them to the context of the Domain Model implementation, which is often the heart of our system. We want to have a clean heart, aren't we?

Some time ago I wrote post about publishing and handling domain events. In addition, in one of the posts I described the Outbox Pattern, which provides us At-Least-Once delivery when integrating with external components / services without using the 2PC protocol. This time I wanted to present a combination of both approaches to complete previous posts. I will present a complete solution that enables reliable data processing in the system in a structured manner taking into account the transaction boundary.

GRASP – General Responsibility Assignment Software Patterns (or Principles). There are far fewer materials on the Internet about this topic, so I decided to bring it closer because I think the principles described in it are as important as the SOLID principles.

Sometimes, when processing a business operation, you need to communicate with an external component in the Fire-and-forget mode. The question that arises is whether we are able to guarantee the atomicity of our business operation from a technical point of view?

In previous post I described how requests input data can be validated on Application Services Layer. I showed FluentValidation library usage in combination with Pipeline Pattern and Problem Details standard. In this post I would like to focus on the second type of validation which sits in the Domain Layer – Domain Model validation.

This time I would like to describe how we can protect our REST API applications from requests containing invalid data (data validation process). However, validation of our requests is not enough, unfortunately. In addition to validation, it is our responsibility to return the relevant messages and statuses to our API clients. I wanted to deal with these two things in this post.

Domain Model encapsulation implementation with Persistence Ignorance in mind using Entity Framework.

In this post I wanted to show you how you can quickly implement simple REST API application with CQRS using the .NET Core.

Today I would like to suggest a less-common, but in my opinion a much better way to organize our codebase. Meet the Feature Folders.

Database change management is not an easy task. It is even more difficult when we are at the beginning of a project where the data model is constantly changing. In this post I will describe what we need to do to have a good database change management mechanism.

In previous post I described two popular ways to manage database changes - state versioning where you keep whole current design of your database and versioning of transitions to desired state. In this post I wanted to show implementation of these two approaches in .NET environment combined together – what I think is the best way to manage database changes.

In this post I would like to discuss places where we can store configuration of our application and warn against keeping sensitive configuration data in the code repository. Additionally, I will show example of configuration based on User Secrets and Environment Variables in .NET Core.

Often the time comes when we need to focus on optimizing the performance of our application. There are many ways to do this and one way is cache some data. In this post I will describe briefly the _Cache-Aside Pattern_ and its simple implementation in .NET Core.

In this post I would like to raise the subject of wasting programmers time which can be easily saved. What's more, it is said time is money so we can save both! This post is especially for management people (managers, directors, CTOs) but developers should also think about whether they use their potential one hundred percent.

From time to time I am asked to do code review of an application. I like doing this, because it is always learning experience. I can see how others program, what problems they have and how they solve them. Except that I can see code written in various conditions and by people with different skills and experience. I prepared a list of 10 popular _"clean code"_ broken rules which I often encounter during this code reviews and I would like to share this list with you.

Domain Event is one of the building blocks of Domain Driven Design. It is something that happened in particular domain and it captures memory of it. We create Domain Events to notify other parts of the same domain that something interesting happened and these other parts potentially can react to.

In previous post about processing multiple instance aggregates of the same type I suggested to consider using eventual consistency approach. In this post I would like to present one way to do this.

When we use Domain Driven Design approach in our application, sometimes we have to invoke some method on multiple instances of aggregate of the same type.