Software Design & Architecture

Software Craftsmanship

Domain-Driven Design

Design Patterns & Principles


I'm a software crafter with 16 years of experience. I work as an independent contractor.

Through DDD, I carefully crafted dozens of rich, extensible, testable, and long-lived business domain models, which along with other principles, patterns, and practices led to delivering high quality software products.
And I can help your company to get the same results.
Poor-quality software is thrown money away
Poor quality software will result in losing customers, damaging reputation, and reduced revenue
A plethora of projects struggles to evolve and are delivered with poor quality, plenty can't adapt quickly enough to the market demands, and some totally fail even before getting launched!

In my experience, the main reasons are:
Over-engineer, weak architecture, poor code quality, anemic domain models, ad-hoc code designs, shallow/naive tests, bad user experience, lack of code quality automation and lack of technical mentorship.

That's a sad truth because software projects are expensive, then companies invest a lot of money motivated by the ROI that a software is suposed to bring them, throught revenue incresement, cost saving or both. Therefore is our job to deliver that benefits to our customers in the best possible way.

I know, developing software is hard, and developing first-class software is harder!
But it's possible, I've had done it many times, and I can help your team do it too.
What I Do
Domain-Driven Design

After years honey my skills and working with DDD to many customers in different fields, I can guarantee you: DDD is not easy, but it pays off a lot.

DDD brings remarkable benefits to many line-of-business software.
Just to mention the main ones:

1. The developers gain a deep knowledge of the business, thus they can meet the real needs of that business;

2. Once skilled with DDD's strategic and tactical patterns, the developers can implement rich, extensible, testable, and long-lived business domain models.

3. There is no translation between domain experts, software developers, and the software because the team develops a common, shared language that all team members speak;

4. Domain experts contribute to software design;

5. Enterprise architecture is better organized;

Tech Lead

As Tech Lead, my main job is:

1. Ensure that every piece of code is crafted with care and quality.

2. Ensure that the code base quality metrics are healthy, and will remain so throughout the project lifecycle.

3. Provide training to developers to update their knowledge regarding the patterns, principles, practices, and technology stack required for the project.

4. Help the developers with their daily basis technical challenges, giving advice, sharing knowledge, and doing code reviews to help them improve their hard and soft skills.

Application Architecture

A well-designed architecture based on a reliable style is a critical point to the success of a project.

Over the years, I've had great results with the Clean Architecture.

Besides the architectural style, I used to implement the CQRS pattern [Commands with EF Core and Queries with Dapper] which provides these key benefits:

• A task-based interface, which significant improves the user experience;

• Keeps the domain model much cleaner as it eliminates the responsibility to provide queries through the model;

• Significantly increases scalability and performance;

Besides the goals your company aims to accomplish with the product, I also assess other requirements like scalability, independent deployment, and data isolation which leads me to propose either Microservices Architecture or Modular Monolith Architecture.

Design Patterns & Principles

To avoid reinvent the wheel, and to guarantee that we are using the battle-tested and documented solutions for the recurrent problems that others already had, whenever necessary, I implement the long-stabelished Design Patterns from [Gamma et al.], [Fowler, P of EAA], as also from [Evans] and [Vernon] when we are working with DDD.

There are some principles that I use in every project because I consider them fundamental:
• DRY (Don’t Repeat Yourself)
• YAGNI (You aren’t gonna need it)
• KISS (Keep It Simple Stupid)
• Defensive Programming (e.g. Guard clauses, Fail Fast)
• Explicit Dependencies (e.g. Well-defined public interface
• Encapsulation
• Low coupling / High cohesion
• Separation of Concerns
• The Boy Scout Rule

CI/CD DevOps pipelines

To guarantee that the code base quality metrics remain healthy throughout the project lifecycle,
I implement two steps of Code Quality Analysis in the CI pipeline, which automatically ensures that each PR compliances with:

The Code Style, Design, Maintainability, Reliability, Security, and Duplication rules that we set at the beginning of the project.

The Unit, Integration, and E2E Tests passing, and also that the required Code Coverage Metric is reached.

This approach is powerful as it prevents non-compliant code from being merged into the main branch.

Automated Tests

A good suite of unit, integration, and e2e tests provides 3 essential guarantees that every serious project needs:

• The code is working as supposed to;

• We can change the code to accomplish the business changes, without the risk of breaking it;

• We can constantly improve the code through refactoring, without the risk of breaking it;

But just writing tests isn't enough, in fact, writing tests randomly and without measurement is pointless. Thus, I follow this approach:

• From the beginning of the project, I set a coverage threshold into the CI to ensure that once a percentage of coverage is reached, that percentage remains, and as the coverage grows, I update the threshold to match it.

That's essential because it ensures that every new PR pushed contains its respective tests.
Otherwise, the coverage decreases to almost 0% as the code base increases over time.

I also focus on testing the code that matters, excluding auto-generated and boilerplate code from the coverage.

About Me
My story

I have 17 years of experience with software development in .NET technology. Over this time, I worked with almost all the .NET technology stack, following their evolution, from the Windows Forms, WPF, Web Forms / MVC / Web Services / WCF, until the more recent and currently Razor Pages, Blazor WASM, and REST Web APIs with .NET Core.

Besides C# and .NET, I have a solid knowledge of Domain-Driven Design (DDD), Software Architecture, Design Patterns, OOP, Defensive Programming, Automated Tests, Refactoring, and Clean Code.

As a software architect and engineer, for the past 5 years, I have focused my career on studying and implementing Modern Web Apps with Clean Architecture, CQRS, and Domain-Driven Design in both microservices and modular monoliths architectural styles.

As a tech lead, besides my job of crafting a reliable architecture, I implement the CI pipeline to ensure that the features are produced with the same quality level throughout the project lifecycle.

Last, but not least, I provide mentorship to each developer, helping them with their daily basis technical challenges, doing code review, giving advice, and sharing knowledge to help them to improve their hard and soft skills.
I also spread the culture of software craftsmanship to encourage professionalism, technical excellence, and customer satisfaction.

I’m an active OSS (open-source software) contributor, author of the Krafted, and organizer of the Software Craftsmanship Lisbon.

Working with
Language Skills
Reading, writing and speaking
  • English


  • Portuguese

    Native speaker.

What coworkers say
Let's talk
Full Name *
Email Address *
Message *

Thanks, your message is sent successfully.