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.
Need Expert Technical Guidance?
Access top-level Fractional CTO services including architecture consulting, roadmap planning, team mentoring, and code review. Perfect for startups and growing teams.
Recent Works
There are threads I’m following, concepts growing quietly that may soon take a more public form.
Language-Driven Design
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
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.
Orbit Software Development
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.
New Published Patterns & Heuristics
A collection of newly documented design patterns, each distilled from real-world challenges and crafted to address recurring problems with clarity and precision.
State/Status Segregation Pattern
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
Behavior as Data Pattern
Design Pattern
It encourages treating business behaviors as first-class data, enabling introspection, scheduling, and dynamic orchestration of logic. download
Sequencer Design Pattern
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:
Mixed Responsibility Smell
Code Smell – Hubristic
This smell highlights the confusion and complexity that arises when a model or component takes on multiple, unrelated responsibilities.
Photography
I’m a very amateur photographer, just someone who enjoys capturing interesting moments and learning how to see the world a bit differently through a lens.
Iran, Arak, Winter 2023👇🏻
Music
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👇🏻
Goal-Oriented Architecture
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: Why We Learn More from Broken Tests than from Perfect OnesDomain-Driven Design School
Eric 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
Language-Driven Design
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
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.
-
Why We Learn More from Broken Tests than from Perfect Ones
(and what my new book, How to Fail Your Test Automation (Easily!), is really about) By Masoud Bahrami People love to find answers to questions they don’t know yet, or to have someone find them on their behalf.But sometimes, the real learning doesn’t come from finding answers. It comes from failing, from seeing something that…
-
Epistemic Testing, Chapter 2 – Is that a Test or an Experiment?
“The Experiment Prepares, the Test Decides.” Before we jump in, fair warning, this chapter gets a bit philosophical. Yeah, less code, more thinking. I know what you’re thinking: Didn’t he promise to stay practical?🤨 Don’t worry, I did, and I will. But some ideas just take a little brewing time. So grab your coffee or…
-
Epistemic Testing, Chapter 01 – What Makes a Test a Test?
“The purpose of a test is not to prove correctness, but to reveal understanding.” We write code to shape ideas into form, but what we really wrestle with every day are the invisible things: assumptions about business logic, intentions buried in variable names, and expectations about how systems will behave when no one is watching.…
-
Technical Debt, More Than Code, More Than a Metaphor
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 on Software Architecture
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…
-
Minimum Viable Experience at the Zero Point of Software Development
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…
-
Backward Refactoring, Part 1: Building Mental Models for Big Code Changes
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…
-
Introducing Sequencer Pattern
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…
-
What I’ve Learned from Math as a Software Engineer
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.…
Tags
acceptance testing Bad Practice Bandwagon book code smell Code Structure Conway’s Law DDD Debt Design Pattern Epistemic Testing Experiment Goal Oriented Architetcure Idea LDD Minimum Viable Experience Orbit Organizational Structure Refactoring Social Rank Software Architetcure System Debt tdd Team Topology Tech Debpt Test test automation