My work sits at the intersection of architecture and hands-on engineering. I care about domain boundaries, observable systems, and code that teams can safely evolve over time. I enjoy turning complexity into systems that are practical to build and resilient to change.
Good software is mostly about clarity. Clear boundaries, clear intent, clear ownership. I've spent enough time in broken codebases to know the opposite is expensive. When the code doesn't reflect how the business actually works, you patch the gap forever. Domain-Driven Design isn't methodology theatre to me. It's the most honest answer I've found to the problem of keeping systems understandable as they grow.
That's not a new idea. But it matters more than most people think, and I've built my approach to architecture around it. CPSA-F certification confirmed what I already knew from practice, but it also sharpened how I think and talk about it. System boundaries need to match business boundaries. Services need names that the business understands. Code needs to say what it does without requiring a wiki.
I use AI-assisted development daily. Not as a shortcut. I think it genuinely changes what's possible as a single engineer. The design space you can explore, the tests you can write, the refactoring you can afford. I use Junie in production work alongside Spring Boot and Kotlin and I'm careful about where it helps and where it introduces risk. Data protection matters. That distinction matters especially when you're building systems that handle sensitive information.
Twelve years in and I still find the hard problems interesting. Cairo to Almere. Java to Kotlin. Monoliths to bounded contexts. The arc is the same. Build systems that teams can safely evolve. Make the implicit explicit. Raise the bar quietly.
Not every project — just the ones where architecture decisions made the difference.
OpenTelemetry Collector, Prometheus, and Jaeger already existed in the infrastructure. But application-level monitoring was missing. Teams had infrastructure visibility but no sense of what the system was actually doing at the business logic level.
Incident response was expensive because it started with guesswork about which service was misbehaving, then digging into traces. No dashboard to see KPIs or health at a glance.
I worked with the team to instrument services with business-relevant metrics. What does a successful order flow look like. Where do customers drop off. Which integrations are failing. We connected these metrics to Grafana dashboards and GCP Alert Policies, integrating critical alerts into MS Teams so incidents surface immediately.
The focus was making the business visible through numbers. Not just infrastructure metrics, but the actual work the system does.
The codebase was a scattered monorepo with multi-module services. Domain logic was spread across modules. No clear boundaries between core domain and supporting concerns. When the business changed how they worked, engineers didn't know which modules to change.
The code didn't reflect how the business described the work. Every change felt risky because coupling was implicit.
I co-led a redesign to extract the domain into a domain-centric. Identified bounded contexts. Reorganized modules around these boundaries, not technical layers. Applied hexagonal architecture pattern so the domain stayed pure and communication with the outside world was explicit.
The work was mostly refactoring and restructuring. Moving code to the right place. Naming things to match how the business talks about the work. Making implicit coupling explicit so it could be managed.
Billie, the customer chatbot, was built on an aging in-house platform. Maintaining it was expensive. The content and flows were tightly coupled to the platform.
We needed to migrate to a proven solution without losing chat history or breaking customer experience.
We split the work into content and engineering. The content team migrated all chat flows to a 3rd party provider. On the engineering side, I worked with the team to design a new architecture. A routing and enriching gateway connects the UI to an adapter service. The adapter abstracts away the 3rd party provider details. If we ever switch providers, only the adapter changes. A fallback channel routes conversations to human customer service when the provider is unavailable.
The pattern was explicit. UI doesn't know about the 3rd party. 3rd party doesn't know about our domain. The gateway and adapter manage the translation.
OpenTelemetry Collector, Prometheus, and Jaeger already existed in the infrastructure. But application-level monitoring was missing. Teams had infrastructure visibility but no sense of what the system was actually doing at the business logic level.
Incident response was expensive because it started with guesswork about which service was misbehaving, then digging into traces. No dashboard to see KPIs or health at a glance.
I worked with the team to instrument services with business-relevant metrics. What does a successful order flow look like. Where do customers drop off. Which integrations are failing. We connected these metrics to Grafana dashboards and GCP Alert Policies, integrating critical alerts into MS Teams so incidents surface immediately.
The focus was making the business visible through numbers. Not just infrastructure metrics, but the actual work the system does.
The codebase was a scattered monorepo with multi-module services. Domain logic was spread across modules. No clear boundaries between core domain and supporting concerns. When the business changed how they worked, engineers didn't know which modules to change.
The code didn't reflect how the business described the work. Every change felt risky because coupling was implicit.
I co-led a redesign to extract the domain into a domain-centric. Identified bounded contexts. Reorganized modules around these boundaries, not technical layers. Applied hexagonal architecture pattern so the domain stayed pure and communication with the outside world was explicit.
The work was mostly refactoring and restructuring. Moving code to the right place. Naming things to match how the business talks about the work. Making implicit coupling explicit so it could be managed.
Billie, the customer chatbot, was built on an aging in-house platform. Maintaining it was expensive. The content and flows were tightly coupled to the platform.
We needed to migrate to a proven solution without losing chat history or breaking customer experience.
We split the work into content and engineering. The content team migrated all chat flows to a 3rd party provider. On the engineering side, I worked with the team to design a new architecture. A routing and enriching gateway connects the UI to an adapter service. The adapter abstracts away the 3rd party provider details. If we ever switch providers, only the adapter changes. A fallback channel routes conversations to human customer service when the provider is unavailable.
The pattern was explicit. UI doesn't know about the 3rd party. 3rd party doesn't know about our domain. The gateway and adapter manage the translation.
These are ideas that have shaped how I build systems.
At iO Digital I worked as a consultant engineer across client engagements while also serving as JVM Chapter Lead, a role built to connect engineers across projects, drive technical alignment, and raise the collective bar. I authored articles on the iO tech hub and helped define what good engineering looked like inside the company. The consulting model sharpened my ability to onboard fast, earn trust quickly, and deliver in unfamiliar Kotlin and Java codebases.
At Kuehne+Nagel I designed and implemented observability architecture using OpenTelemetry, establishing metrics, alerting, and dashboards with Grafana and Prometheus that improved production resilience. I also led domain model redesign efforts, removing technical debt and aligning code with current business rules. I work in a DevOps manner, taking ownership of deployments, monitoring, and production stability and I bring test-first practices and a habit of raising engineering quality across the team.
My time at Bol. gave me deep familiarity with high-availability systems operating at scale. Event-driven architectures using Kafka and Google Pub/Sub. Containerized workloads on Kubernetes. CI/CD pipelines through GitLab. I was hands-on across backend and supporting interfaces in Kotlin and Java. As part of the Architecture Circle I reviewed service designs across domains and guided teams toward consistent patterns. As technical lead I shaped onboarding and set the engineering bar for the team.
I got into software engineering because I love building things. The same instinct that made me take apart toys as a kid eventually led to Computer Science at Modern Academy and then to a career where I get to design systems from scratch, make hard decisions, and watch them hold up under real load.
Java was my first professional language. I reached for it on day one at Ferrycode in Dubai and it shaped how I think about type safety, verbosity as clarity, and the JVM as a long-term investment. Over time Kotlin became my primary language, not because Java isn't good, but because Kotlin removes friction without hiding the model. I've been building production systems in both for over a decade and they still interest me.
Starting at Ferrycode exposed me to the full cycle. Requirements to customer training. That foundation shaped how I think about ownership and delivery. From there I moved through individual contributor work to focusing on technical impact, from single-team work to cross-domain architecture, from building features to building the conditions that let teams build well.
Cairo to the Netherlands in 2018 was a turning point. Work scaled differently at Bol.. High-availability systems with Kafka and GCP. Event-driven architecture at scale is a different discipline. The consulting model at iO Digital sharpened how I onboard fast and earn trust in unfamiliar codebases. Now at Kuehne+Nagel I get to design the observability infrastructure that makes everything else possible.
Language-wise, I'm native Arabic, fluent in English (my working language for the past decade), and learning Dutch since moving to Almere. Most of my writing and thinking happens in English. The CPSA-F certification from iSAQB grounded my approach to architecture in formal thinking, but it confirmed what I already knew from practice.
I write about engineering because writing clarifies thinking. Curious about how AI-assisted development fits into real workflows, not the hype. I believe good architecture is mostly about honesty. The rest follows.
If you want to think out loud about distributed systems, domain design, or how AI fits into a real engineering workflow, I am genuinely here for that. I have opinions about bounded contexts, strong feelings about observability, and a possibly unhealthy interest in why monoliths keep winning. If you have an interesting problem or just want to compare notes, reach out.