Software is everywhere, quietly shaping the systems we rely on every day. I’ve spent over a decade immersed in this world, starting as a developer, then evolving into a designer of software that aims not just to function, but to solve real, meaningful problems. Along the way, I’ve learned that great software starts with asking better questions, not just writing better code.
This site is where I share what I’ve learned about domain modeling, software architecture, and problem discovery, share practical insights, and examine how software can be designed with greater precision and purpose. I write about patterns, principles, and practices like Language-Driven Design, Exploratory Domain Discovery, and Orbit Software Development.
There are threads I’m following, concepts growing quietly that may soon take a more public form.
I’m currently working on Language-Driven Design, a book that explores a paradigm shift in how we model and design complex systems, by treating the language of the domain as the foundation of both understanding and architecture.
Exploratory Domain Discovery is a method I’ve been developing to guide teams in navigating complex problem spaces, prioritizing deep understanding and adaptive modeling over premature precision.
I’ve also been developing Orbit Software Development, an agile approach to building software that centers on evolving goals, continuous learning, and the natural alignment of teams, architecture, and intent.
A collection of newly documented design patterns, each distilled from real-world challenges and crafted to address recurring problems with clarity and precision.
Design Pattern
This pattern advocates separating an entity’s transient state from its long-term status to clarify modeling and avoid ambiguity in domain behavior. download
Design Pattern
It encourages treating business behaviors as first-class data, enabling introspection, scheduling, and dynamic orchestration of logic. download
I’m pleased to introduce the Sequencer Pattern, a new design pattern I have formalized to model values that progress step-by-step within a set of boundaries. This pattern is a concept from my upcoming book, Language-Driven Design.
From the ticks of a clock to currency rollovers, animations, and simulations, this pattern gives a name and structure to something you’ve likely built many times before.
Read the full article and see the code examples here:
Code Smell – Hubristic
This smell highlights the confusion and complexity that arises when a model or component takes on multiple, unrelated responsibilities.
As an amateur musician, I enjoy composing and experimenting with sound, it’s a creative outlet that helps me think differently and reconnect with rhythm and emotion.
Listen to my Setar improvisation on SoundCloud👇🏻
I explore architecture that begins with intent. In Goal-Oriented Architecture, software is shaped around the goals it exists to achieve, not just data structures or workflows. This perspective brings clarity, alignment, and purpose to system design, making every part of the codebase traceable to real-world outcomes.
Read more: Technical Debt, More Than Code, More Than a MetaphorEric Evans’ DDD has always been an inspiration and game changer for me. This book has played a huge role in shaping my mind as a software developer on how to think practically, effectively and constructively about this field, and sharpening my modeling and design lens in this field as a key driver of “discovering better ways to develop software”!
As a DDD expert and teacher, I launched DDD School as a startup to educate, consult and share my thoughts, learning and experience in modeling and designing software development
I’ve been working on writing my book titled Language-Driven Design. At its core, the book explores the profound impact of language on how we think and perceive the world around us. This idea has deep roots in philosophy, particularly in the study of the relationship between language and thought. Language-Driven Design (LDD) emphasizes the central role language plays in how we understand, design, and architect software. It argues that the words we choose, both in code and in conversation, shape not only our solutions but also the way we conceptualize problems in the first place.
Exploratory Domain Discovery (EDD), introduced by me, is a collaborative and powerful approach to understanding complex domains by exploring their core concepts and cyclical patterns.
Unlike traditional modeling techniques, EDD starts from the desired outcome and works backward to uncover the main point that drives the domain, enabling teams to build shared understanding and make strategic decisions with clarity.
Where the Term Comes From Ward Cunningham, one of the original authors of the Agile Manifesto, coined the term technical debt to describe the hidden cost of taking shortcuts in code, decisions that make future changes harder, slower, and more expensive. The idea is simple, when you borrow time by implementing a quick-and-dirty solution now,…
Introduction- Software Architecture is Alive People often ask me: What exactly is software architecture? Isn’t architecture just for buildings? It’s a fair question. When we hear the word architecture we usually picture tall skyscrapers, bridges, or even cozy houses. But software architecture isn’t that different, it’s the blueprint of your system. It’s the plan that…
Every creative journey begins with a blank page. For writers, it is the empty sheet waiting for its first word. For artists, it is the untouched canvas. In software, the blank page is more than a code file, it represents a unique moment of anticipation, fear, and possibility: the Zero Point. Nothing exists yet: no…
Introduction If you’re a software developer, or even a product person, you’ve likely encountered the challenge of code refactoring. Over years of building software, I’ve developed a new way of thinking about this process, especially when dealing with large, complex codebases. What I’m sharing here is my own approach, a pattern, a mindset, and a…
Abstract The Sequencer Pattern is a design pattern that addresses a common but often overlooked problem in software: how to model values that progress step-by-step within boundaries, optionally wrapped around, and are often composable to create larger structures. From timekeeping systems to currency calculations, this pattern surfaces across countless domains. The key features of a…
My Two Confessions Let me start with two confessions, two things I’ve learned the hard way as a software engineer. First, the more I understand the problem, the better my chance of building the right solution. That’s something DDD taught me early on: to listen deeply, study the domain, and let it shape the model.…
Abstract Goal-Oriented Software Architecture is a new architectural style that positions business intent as the primary structuring unit of a software system. It directly addresses the chronic misalignment between software structure and business intent, offering a radically different model where each business goal is encapsulated, executable, and traceable as a first-class citizen. This document outlines…
Introduction Have you ever wondered why some words appear far more frequently than others in a language? Or why a handful of cities dominate a country’s population? These seemingly disparate phenomena share a surprising commonality: they often follow a simple yet profound pattern known as Zipf’s Law. What is Zipf’s Law? Zipf’s law is an…
The Perils of the Bandwagon Effect in DDD from Wikipedia The bandwagon effect is a psychological phenomenon where people adopt certain behaviors, styles, or attitudes simply because others are doing so. Introduction The software development landscape is constantly evolving, with new technologies, frameworks, and methodologies emerging at a rapid pace. While innovation is essential, it’s…
Introduction There are many myths about *test-ish in software development. What is the essence of software testing? What is the purpose of a “unit testing”-kind of software testing? Should we consider this a “unit test” or an “integration test”? Why do we really need someone to replace the “T” in “TDD” with a “B” and…
acceptance testing Bad Practice Bandwagon code smell Code Structure Conway’s Law DDD Debt Design Pattern Experiment Goal Oriented Architetcure Idea LDD Minimum Viable Experience Organizational Structure Refactoring Social Rank Software Architetcure System Debt tdd Team Topology Tech Debpt test automation