Rethinking Domain Driven Design: Beyond Tactical Patterns

In recent years, Domain Driven Design (DDD) has become a buzzword in the software development community, often surrounded by discussions focused on its tactical patterns: entities, value objects, repositories, services, aggregates, and more. This mainstream portrayal of DDD has, unfortunately, done a disservice to the software community. The emphasis on these complex patterns has led many to view DDD as overly complicated and inaccessible, particularly for projects that appear to have simpler domains. The question arises: why entangle your project in the web of DDD's tactical patterns if they seem unnecessary?

The Misguided Focus and Its Consequences

The vast majority of content and discussions available online revolve around DDD's tactical aspects, obscuring its true essence and benefits. This skewed focus has made it easy to lose sight of what DDD fundamentally aims to achieve: the strategic advantage of clearly defined boundaries within your domain, encapsulated by the concept of a bounded context. Unfortunately, for many newcomers to DDD, the bounded context—the cornerstone of DDD's strategic patterns — is not what they first encounter. Instead, they are introduced to DDD through tutorials or sample applications that dive straight into its tactical patterns without establishing a foundational understanding of the domain itself.

Java Under the Hood [Videos]

Java is a high-level programming language, which means that we don't need to know the internals of the language and how it works under the hood to be a Java developer. However, if you want to lead back-end projects, earn a higher salary, be respected and admired, you will need to learn what it takes to run a Java program.

I have recorded a series of videos showing essential parts of Java that you need to know to call yourself a senior Java developer.

We Are Structuring Our Code Wrongly!

It is time to stop structuring your code as a beginner's framework that tutorials once taught you.

By now, you should be capturing the domain knowledge in working code and protecting that knowledge in your context from contamination and overreaching from other contexts. What do ProductRepository and BasketRepository have in common? Nothing. Both address different problems, so why group them together? 

gRPC For Production

When starting with gRPC there are many resources setting out what gRPC is, where it originated from and how to create basic service and client. All those tutorials do a very good job in helping the developers to get started using gRPC in their projects. We can find materials talking about gRPC server, stub client, interceptors, protobuf, encrypted connection, load balancing but hardly we find all this together and prepared for a real production scenario. Deployments to production are not discussed and available resources are sparse.

There are some projects that provide a collection of handy features that can help you to set up gRPC communication in a reliable way but they are all generic building blocks without an initial structure that you can evolve from.

Protobuf API Contract Guideline

This post provides guidelines to manage APIs using protocol buffers. Check out this blog post to learn more about Protobuf API contract management.

API Contracts

API contracts describe the surface area of the request and response of each individual API method being offered. It is something that both API providers and API consumers can agree upon and get to work developing and delivering, and then integrating and consuming. An API contract is a shared understanding of what the capabilities of a digital interface are, allowing for applications to be programmed on top of.

The Modern Way of Managing APIs Using Protobuf and OpenAPI

I am a tech-enthusiast, and I love sharing new technologies, ideas, and innovations about software development. This time, I will be talking about API contract management with Protobuf and OpenAPI.

One of the most important aspects of microservices-based applications is the ability to deploy microservices completely independent of one another. To achieve this independence, each microservice must provide a versioned, well-defined contract to its clients. Each service must not break contracts until it's known that no other microservice relies on a particular contract version.

Best Practices in Software Development: Interface Overuse

“Program to interface, not to implementation” doesn't mean you should pair each and every one of your domain classes with a more or less identical interface. In doing so, you are violating YAGNI, and lowering the readability and maintainability of your codebase.

Extracting an interface from a class just so it has one, has this annoying feature that whenever you try to navigate using your IDE, you end up in the interface rather than the implementation itself. I see no practical use case in jumping to the signature declaration instead of the implementation itself. It’s annoying, a waste of time, a huge overkill, and completely useless, in general. What would you say to an experienced developer that adds an interface to a DTO class?!

You Are Bad at Hiring Good Engineers

I have never asked a puzzle or a trick question to find some obscure algorithmic approach. It had always been instead asking to come up with design solutions and creative implementation for real-world problems.

But when I got to the other side as a candidate, I have never been lucky — not even once. It’s always some shitty puzzle or a whiteboarding exercise about some obscure algo that no one does on a typical day job. The software industry has a long way to go to be even considered “mature”.

Programming Microservices Communication With Istio [Screencast]

This is the second part of a series of articles that present a service mesh project. If you haven’t seen part 1, check it out.

The idea of this project is to provide you with a bootstrap for your next distributed system architecture. This project will definitely help you to get an understanding of how to solve distributed application challenges and save you a lot of time in setting up your next service mesh.

Programming Microservices Communication With Istio

Microservices are great but they are also a pain to maintain. With so many moving components, microservices make it difficult to maintain and identify the bottlenecks. The mindset has to be changed and applications need to be designed for failure. 

Applications are split into multiple smaller services and they should be. These small services should be interconnected. They should know where the other services live and how to connect with them. They should be consistent and highly available. The connections should be intelligent and configurable. These services should be secured, traffic between services should be encrypted, requests should be properly authorized and authenticated. Since these services scale up and down autonomously, it is important to monitor and observe them for any issues, errors, exceptions, time lag, and other things.

Lambda Architecture: How to Build a Big Data Pipeline, Part 1

The Internet of Things is the current hype, but what kinds of challenges do we face with the consumption of big amounts of data? With a large number of smart devices generating a huge amount of data, it would be ideal to have a big data system holding the history of that data. However, processing large data sets is too slow to maintain real-time updates of devices. The two requirements for real-time tracking and keeping results accurately up to date can be satisfied by building a lambda architecture.

"Lambda architecture is a data-processing architecture designed to handle massive quantities of data by taking advantage of both batch and stream-processing methods. This approach to architecture attempts to balance latency, throughput, and fault-tolerance by using batch processing to provide comprehensive and accurate views of batch data, while simultaneously using real-time stream processing to provide views of online data."