September 18, 2023

Practical SOLID in Golang: Interface Segregation Principle

We continue our journey through the SOLID principles by discussing the one that has a profound impact on code design: The Interface Segregation Principle.

When beginners embark on their programming journey, the initial focus is typically on algorithms and adapting to a new way of thinking. After some time, they delve into Object-Oriented Programming (OOP). If this transition is delayed, it can be challenging to shift from a functional programming mindset. However, eventually, they embrace the use of objects and incorporate them into their code where necessary, sometimes even where they’re not needed. As they learn about abstractions and strive to make their code more reusable, they may overgeneralize, resulting in abstractions applied everywhere, which can hinder future development.

September 18, 2023

Practical SOLID in Golang: Liskov Substitution Principle

We continue our journey through the SOLID principles by presenting the one with the most complex definition: The Liskov Substitution Principle.

I’m not really a fan of reading. Often, when I do read, I find myself losing track of the text’s topic for the past few minutes. Many times, I’ll go through an entire chapter without really grasping what it was all about in the end. It can be frustrating when I’m trying to focus on the content, but I keep realizing I need to backtrack. That’s when I turn to various types of media to learn about a topic.

September 18, 2023

Practical SOLID in Golang: Open/Closed Principle

We continue our journey through the SOLID principles by presenting the one that enhances the flexibility of applications: The Open/Closed Principle.

Many different approaches and principles can lead to long-term improvements in our code. Some of them are well-known in the software development community, while others remain somewhat under the radar. In my opinion, this is the case with The Open/Closed Principle, represented by the letter O in the word SOLID. In my experience, only those genuinely interested in SOLID principles tend to understand what this principle means. We may have applied this principle without even realizing it in some instances, such as when working with the Strategy pattern.

🍺 Support my Blogging work

Join the Ompluscator's Blog Community

Hey there! Want to be part of our awesome community? Just drop your email below, and we'll send you the good stuff – cool articles, fun updates, and more. No spam, we promise!

September 18, 2023

Practical SOLID in Golang: Single Responsibility Principle

We start a journey through the essential principles in software development by presenting the most well-known one: The Single Responsibility Principle.

There aren’t too many opportunities for a breakthrough in software development. They usually arise from either rewiring our logic after initial misunderstandings or filling in gaps in our knowledge. I appreciate that feeling of deeper understanding. It can happen during a coding session, while reading a book or an online article, or even while sitting on a bus. An internal voice follows, saying, “Ah, yes, that’s how it works.” Suddenly, all past mistakes seem to have a logical reason, and future requirements take shape.

September 18, 2023

Practical DDD in Golang: Specification

Use cases of the versatile Specification pattern include validation, creation, and querying.

There are not many code structures that bring me joy whenever I need to write them. The first time I implemented such code was with a lightweight ORM in Go, back when we didn’t have one. However, I used ORM for many years, and at some point, when you rely on ORM, using QueryBuilder becomes inevitable. Here, you may notice terms like “predicates”, and that’s where we can find the Specification pattern.

September 18, 2023

Practical DDD in Golang: Repository

Implementing the Anti-Corruption layer using a well-known DDD pattern: Repository.

Today, it is hard to imagine writing an application without accessing some form of storage at runtime. This includes not only writing application code but also deployment scripts, which often need to access configuration files, which are also a type of storage in a sense. When developing applications to solve real-world business problems, connecting to databases, external APIs, caching systems, or other forms of storage is practically unavoidable. It’s no surprise, then, that Domain-Driven Design (DDD) includes patterns like the Repository pattern to address these needs.

September 18, 2023

Practical DDD in Golang: Factory

The story about Domain-Driven Design (DDD) continues by introducing a legendary pattern: the Factory.

When I wrote the title of this article, I was trying to remember the first design pattern I had learned from “The Gang of Four”. I think it was one of the following: Factory Method, Singleton, or Decorator. I am sure that other software engineers have a similar story. When they started learning design patterns, either Factory Method or Abstract Factory was one of the first three they encountered. Today, any derivative of the Factory pattern is essential in Domain-Driven Design, and its purpose remains the same, even after many decades.

September 18, 2023

Practical DDD in Golang: Aggregate

One DDD pattern to rule them all.

I have spent years understanding and practicing the DDD approach. Most of the principles were easy to understand and implement in the code. However, there was one that particularly caught my attention. I must say that the Aggregate pattern is the most critical one in DDD, and perhaps the entire Tactical Domain-Driven Design doesn’t make sense without it. It serves to bind business logic together. While reading, you might think that the Aggregate resembles a cluster of patterns, but that is a misconception.

September 17, 2023

Practical DDD in Golang: Module

The discussion about DDD in Go now leads us to explore a cluster of highly cohesive structures known as Modules.

At first glance, Modules may not seem like a typical software development pattern, especially when we often associate patterns with specific code structures or behaviors. This can be particularly confusing when considering Go Modules. These modules consist of closely related Go Packages, are versioned, and released together, serving as a form of dependency management in Go. Since both Go Modules and Packages impact the project’s structure, it raises the question of their relationship with the DDD pattern known as Module.

September 17, 2023

Practical DDD in Golang: Domain Event

The tale of DDD in Go advances by introducing a fundamental building block that mirrors real-world events — the Domain Event.

In many cases, Entities are the most effective means of representing elements in Domain-Driven Design. Together with Value Objects, they can provide a precise reflection of our Problem Domain. However, sometimes, the most apt way to depict a Problem Domain is by employing events that transpire within it. In my experience, I increasingly attempt to identify events and then discern the Entities associated with them. Although Eric Evans didn’t cover the Domain Event pattern in the first edition of his book, today, it’s challenging to fully develop the domain layer without incorporating events.

Articles

${title}