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.
