DEV Community: kevinbkdev

Software architecture 2025 — My thoughts

kevinbkdev — Mon, 28 Apr 2025 07:34:46 +0000

Hello guys,

It’s been a long time since my last blog at the end of 2024. Now I’m back with a new series about Software Architecture in 2025 — a year marked by the rapid growth of AI and what seemed like a downturn in tech.

Despite that, I still believe in the crucial role of humans in building strong and meaningful software with solid architecture.

At the same time, I’ve noticed how important it is for architecture to align with the business — keeping things simple, fast, and most importantly, delivering real value and revenue. It’s not just about complex technical systems anymore.

This blog is an overview, sharing some brief insights and personal thoughts on three architectural approaches I've worked with over the past few years. It’s a quick reflection based on my experience with each one. I’ll dive deeper into the details in the next three blog posts, each dedicated to one architecture.

I. Mono-repo

Mono-repo (short for monolithic repository) is a software development strategy where all code for multiple projects, services, or components is stored in a single version-controlled repository.

1. Context

The idea behind mono-repo is to centralize development efforts. Instead of managing separate repos for each service or module, teams work from a unified codebase. This approach is especially common in large-scale organizations like Google or Meta, where consistency, visibility, and cross-team collaboration are crucial.

2. Key points

Centralized tooling: Easier to enforce code standards, formatting, and testing workflows
Atomic changes: Developers can update multiple services/modules in a single commit
Dependency management: Shared libraries are easier to maintain and upgrade
Challenges at scale: Build times, CI/CD performance, and repo size can become pain points
Code ownership: Needs clear boundaries and team agreements to avoid conflicts

3. Personal thoughts

In my experience, mono-repo works best when teams value consistency and tight integration. It's great for early-stage startups or products with shared components. But as the codebase and team grow, without proper tooling and governance, it can become a bottleneck.
Tooling like Nx, Bazel, or Turborepo can really help mitigate scaling issues. Still, the decision to go mono-repo should depend on the team culture, product scope, and growth expectations.

II. Microservice

Microservice architecture is a design approach where a system is broken down into small, independent services that communicate over a network — usually via HTTP, gRPC or messaging queues.

Each microservice is responsible for a specific business capability and can be developed, deployed, and scaled independently.

1. Context

Microservices became widely popular as a response to the limitations of monolithic architectures. They offer flexibility in choosing tech stacks per service, enable faster team autonomy, and improve scalability. However, they also introduce new layers of complexity — particularly in communication, data consistency, and observability.

2. Key points

Decoupled services: Teams can iterate faster and independently
Scalability: Only scale the services that need it
Resilience: Failures can be isolated, avoiding total system downtime
Operational overhead: Requires robust DevOps practices, observability, and service discovery
Data management: Handling distributed data and eventual consistency is hard
Communication patterns: REST, gRPC, message brokers — choosing the right one matters

3. Personal thoughts

Microservices bring a lot of value — when used for the right problems. I've seen them shine in systems with clearly separated domains and fast-moving teams. But I've also seen projects over-engineered with too many services too early, leading to slower development and painful debugging.
In 2025, with better tooling and cloud-native ecosystems (like Kubernetes and service meshes), microservices are more manageable — but still require discipline. Start simple, and split when necessary, not because it’s trendy.

III. DDD & hexagon

Domain-Driven Design (DDD) and Hexagonal Architecture are architectural patterns that aim to place business logic at the core of software design — making systems more maintainable, flexible, and aligned with real-world problems.

1. Context

DDD, introduced by Eric Evans, emphasizes understanding the business domain deeply and modeling it in code. It promotes the use of a ubiquitous language shared between developers and domain experts, and encourages separation of concerns through concepts like entities, value objects, aggregates, and bounded contexts.

Hexagonal Architecture (also known as Ports and Adapters) complements DDD by structuring code in a way that keeps the domain logic independent of technical concerns. Inputs (like HTTP, CLI, queues) and outputs (like databases or external APIs) are treated as interchangeable adapters — allowing the domain logic to remain clean and testable.

2. Key points

Business-centric design: The domain is the heart of the system
Bounded contexts: Clear boundaries between different parts of the system
Separation of concerns: Infrastructure and domain layers are isolated
Adaptability: Easier to change technology without touching core logic
Testability: Domain logic can be tested without external dependencies
Steeper learning curve: Requires discipline and upfront modeling effort

3. Personal thoughts

DDD and hexagonal architecture changed the way I think about building systems. When applied correctly, they lead to software that's easier to evolve and reason about, especially as the system grows.
But they’re not silver bullets — for small projects or MVPs, the overhead might not be worth it. I’ve found them most effective in complex business domains, where understanding the core logic deeply is critical to success.

Summary

In 2025, building great software isn’t just about using the latest technologies — it’s about choosing the right architecture that fits both the team's capabilities and the business goals.

Mono-repo simplifies collaboration and dependency management but needs strong tooling and clear ownership.
Microservices offer flexibility and scalability, yet come with operational complexity that requires maturity to handle well.
DDD & Hexagonal Architecture bring clarity to complex systems by focusing on business logic first, but they require a thoughtful, disciplined approach.

Each approach has its place. There’s no one-size-fits-all. The key is to deeply understand your product, your team, and your long-term vision — and then design your architecture to support that, not the other way around.

Stay tuned for the upcoming deep-dives into each of these architectures, where I’ll share more lessons, mistakes, and real-world insights from my journey.

Maybe you missed these 12 awesome Git commands

kevinbkdev — Mon, 19 Feb 2024 07:01:50 +0000

In today's development landscape, Git has become an indispensable tool for developers at every level, from newcomers to seasoned professionals. It's a tool we rely on daily, but have you ever wondered about the lesser-known Git commands that could enhance your workflow?

Let's explore 12 Git commands that might just surprise you with their usefulness and efficiency.

1. Git stash

Git stash is useful commands that help you in Git workflows with many branches and many people effectively. In the real world, have ever seen a case that you are developing on the branch and your leader said “hey man, I need your urgent fix on another branch”, how to save your current version code locally but not make commit?

//save unchange commits
git stash 

//restore commits
git stash pop

Cre: Scaler

2. Git diff

In case you need to compare between un-saved changes and the previous commit, git diff is the command you should know in using Git with commands besides using GUI or Git extension.

git diff

3. Git rebase

Rebasing is a powerful besides on Merge feature in Git with the same purpose but with different methods. The most awesome feature that git rebase brings is keeping the Git tree clean, straight and avoiding “the diamond shape” in the Git graph.

//checkout branch featuire
git switch feature 

//rebase feature into main
git rebase -i main feature

Cre: ByteByteGo

4. Git cherry-pick

The git cherry-pick command is used to apply a specific commit from one branch to another. This can be useful when you want to selectively bring in changes from one branch to another without merging the entire branch.

git cherry-pick <commit-hash>

5. Git log

With git log, you can show all commit logs in Git including commit hash, commit message, commit author, and the date that the commit was committed.

git log

6. Git commit —amend

If you ask how can I change my commit information, the git commit --amend is your answer. You can change information of that commit including message and author.

git commit --amend -m "New commit message" --author="Author Name <email@example.com>"

7. Git tag

Tagging versions in Git using the git tag command is a common practice to mark significant points in your repository, such as releases or milestones. You can tag commits with version numbers or any other meaningful identifier.

git tag -a v1.0 -m "Release version 1.0" <commit-hash>

8. Git checkout .

In case you need to clean up all changes locally or add code to show logs on the server for tracing errors and hot fixing, git checkout . is the powerful command that you should know.

git checkout .

9. Git reset

git reset is a powerful command in Git that allows you to reset the current HEAD to a specified state. It's commonly used to undo changes, move the HEAD to a different commit, or unstaged changes.

If you want to move the HEAD to a specific commit but keep the changes in your working directory and staging area, you can use soft reset. If you want to completely undo the last commit and discard the changes from that commit, use git reset hard.

//soft reset
git reset --soft <commit-hash>

//hard reset
git reset --hard HEAD^

10. Git revert

git revert is a command used to create a new commit that undoes the changes made by a specific commit or commits. Unlike git reset, which alters the commit history, git revert maintains the history by creating a new commit that undoes the changes introduced by previous commits.

git revert <commit-hash>

11. Git remote —prune

The git remote --prune command is used to remove any remote-tracking references that no longer exist on the remote repository. Over time, these references can become outdated if branches are deleted or renamed on the remote repository.

git remote prune origin

With this command, you can sync up locally with your remote git workspace.

12. Git filter-branch

git filter-branch is a powerful but potentially dangerous command in Git that allows you to rewrite the commit history of a repository. It's typically used to rewrite commits to apply various filters or transformations.

This command can be useful for tasks such as removing sensitive data from the history, rewriting commit messages, or splitting a repository into multiple repositories.

For example, in case you need to rewrite the author of commit history in the repository, you can use this command followed in below script.

#!/bin/sh
git filter-branch --env-filter '
OLD_EMAIL="your_old_email"
CORRECT_NAME="your_new_name"
CORRECT_EMAIL="your_new_email"

if [ "$GIT_COMMITTER_EMAIL" = "$OLD_EMAIL" ]; then
    export GIT_COMMITTER_NAME="$CORRECT_NAME"
    export GIT_COMMITTER_EMAIL="$CORRECT_EMAIL"
fi

if [ "$GIT_AUTHOR_EMAIL" = "$OLD_EMAIL" ]; then
    export GIT_AUTHOR_NAME="$CORRECT_NAME"
    export GIT_AUTHOR_EMAIL="$CORRECT_EMAIL"
fi
' --tag-name-filter cat -- --branches --tags