Posts List

Introduction to DDD Lite: When microservices in Go are not enough

Introduction to DDD Lite: When microservices in Go are not enough

When I started working in Go, the community was not looking positively on techniques like DDD (Domain-Driven Design) and Clean Architecture. I heard multiple times: “Don’t do Java in Golang!", “I’ve seen that in Java, please don’t!". These times, I already had almost 10 years of experience in PHP and Python. I’ve seen too many bad things already there. I remember all these “Eight-thousanders” (methods with +8k lines of code 😉) and applications that nobody wanted to maintain.

The Repository pattern: a painless way to simplify your Go service logic

The Repository pattern: a painless way to simplify your Go service logic

I’ve seen a lot of complicated code in my life. Pretty often, the reason of that complexity was application logic coupled with database logic. Keeping logic of your application along with your database logic makes your application much more complex, hard to test, and maintain. There is already a proven and simple pattern that solves these issues. The pattern that allows you to separate your application logic from database logic. It allows you to make your code simpler and easier to add new functionalities.

Introducing Clean Architecture by refactoring a Go project

Introducing Clean Architecture by refactoring a Go project

The authors of Accelerate dedicate a whole chapter to software architecture and how it affects development performance. One thing that often comes up is designing applications to be “loosely coupled”. The goal is for your architecture to support the ability of teams to get their work done—from design through to deployment—without requiring high-bandwidth communication between teams. Accelerate If you haven’t read Accelerate yet, I highly recommend it.

Introducing basic CQRS by refactoring a Go project

Introducing basic CQRS by refactoring a Go project

It’s highly likely you know at least one service that: has one big, unmaintainable model that is hard to understand and change, or where work in parallel on new features is limited, or can’t be scaled optimally. But often, bad things come in threes. It’s not uncommon to see services with all these problems. What is an idea that comes to mind first for solving these issues? Let’s split it into more microservices!

Combining DDD, CQRS, and Clean Architecture by refactoring a Go project

Combining DDD, CQRS, and Clean Architecture by refactoring a Go project

In the previous articles, we introduced techniques like DDD Lite, CQRS, and Clean (Hexagonal) Architecture. Even if using them alone is beneficial, they work the best together. Like Power Rangers. Unfortunately, it is not easy to use them together in a real project. In this article, I will show you how to connect DDD Lite, CQRS, and Clean Architecture in the most pragmatic and efficient way. Why should I care? Working on a programming project is similar to planning and building a residential district.

Repository secure by design: how to sleep better without fear of security vulnerabilities

Repository secure by design: how to sleep better without fear of security vulnerabilities

Thanks to the tests and code review, you can make your project bug-free. Right? Well… actually, probably not. That would be too easy. 😉 These techniques lower the chance of bugs, but they can’t eliminate them entirely. But does it mean we need to live with the risk of bugs until the end of our lives? Over one year ago, I found a pretty interesting PR in the harbor project. This was a fix for the issue that allowed to create admin user by a regular user.

Software Dark Ages

Software Dark Ages

A couple of years ago, I worked in a SaaS company that suffered from probably all possible issues with software development. Code was so complex that adding simples changes could take months. All tasks and the scope of the project were defined by the project manager alone. Developers didn’t understand what problem they were solving. Without an understanding the customer’s expectations, many implemented functionalities were useless. The development team was also not able to propose better solutions.



Share on Hacker News
Share on Reddit

Do you like our posts and you are still not subscribed to our newsletter? We are not sending any spam - just notifications about new content.