Software development: defining the architecture or working within an existing one.

I have worked in software development for more than twenty-five years. The Microsoft ecosystem is my main reference point, alongside the web technologies each project needs.

On the backend I work mainly with .NET and ASP.NET Core: APIs, application rules, data and integrations. I have followed the platform from .NET Framework to current .NET versions, working for small and medium-sized businesses as well as in enterprise settings.

On the frontend I have extensive experience with Angular: first AngularJS, then Angular from its earliest versions. I have also used React on large projects. The product and the team determine the choice of tool; in either case, I aim to build interfaces that remain manageable as features and teams grow.

I do not start with the name of an architecture. I start with the rules the code must express and the changes it will need to support.

In modules with significant business logic, I separate the domain, use cases and technical details. The domain contains the customer's concepts and business rules; the application layer coordinates operations; databases, messaging and external APIs are integration details. This applies the central principle of Clean Architecture: system rules should not depend directly on the technology used to store or expose them.

I often organise work by feature with a Vertical Slice approach. The endpoint, request, handler and validation for a use case stay close together, so someone changing a feature can follow its path without searching distant folders. Clean Architecture and Vertical Slice address different questions: the former concerns dependencies, the latter how the code is grouped.

I use dependency injection to make dependencies explicit, and separate commands, queries and their handlers when that clarifies the use cases. These tools need restraint: extra layers and abstractions can make a simple feature harder to follow.

Separating modules within an application and deploying independent services are different decisions.

I consider microservices when functional boundaries are clear and there is a real benefit to evolving or releasing the parts independently. That autonomy has a cost: network communication, error handling, monitoring and release coordination. In other contexts, one application with well-defined modules may be more suitable.

I have worked on projects using Azure Service Bus or RabbitMQ for asynchronous communication. One component can publish an event and others can react without the producer calling each recipient directly. This decoupling requires care with delays, duplicate messages, errors and traceability. In existing products I work within the established architecture, helping with integrations and diagnosing flows; when I own the design, I evaluate whether this approach is justified by the problem.

Important rules should be understandable to people who know the product and remain testable over time.

I apply Domain-Driven Design ideas to the extent the problem calls for: a shared language with product experts, boundaries between functional areas and business rules placed where they can be understood and tested. Not every application needs every DDD pattern; in team projects, I start with the patterns already adopted and the decisions of those leading the architecture.

Automated tests check behaviour and protect future changes. I use TDD when writing a test first helps pin down a rule or an edge case; in other situations I add tests during development or reproduce a bug with a test before fixing it. Testing an API is also useful before its client is ready. Where tests are required for a pull request to be approved, I follow the team's requirements. A coverage percentage, however, is different from the quality of the checks.

Architecture should help a project grow, rather than become an end in itself.

A system that exchanges events does not necessarily need event sourcing. With event sourcing, events form a persistent history from which the system's state is rebuilt. This may help when a process's evolution must be preserved, but it adds work around versioning, projections and long-term management. I would consider it only for a concrete need.

I apply the same criterion to layers, patterns and distributed services: start with a proportionate structure and evolve it when rules, boundaries or loads justify a more elaborate solution. In projects I lead, I take responsibility for those choices; when I work on someone else's product, I help improve it within the team's responsibilities and constraints.