💡Sequencer Design Pattern

In my experience modeling and designing complex domains, I've utilized not only existing design patterns and heuristics but also developed a unique perspective on problems.

I’ve observed that many issues inherently possess a sense of repetition and circularity. For example, an hour can be modeled as a sequencer that completes 24 cycles, encompassing minutes that each complete 60 cycles.

Similarly, consider how a dollar is represented in cents; after every 100 cents, it wraps into a dollar.

To address these types of problems, I introduced the Sequencer Design Pattern, which can be beneficial in various situations.

Read the article and see examples here👇
https://masoudbahrami.com/article/introducing-sequencer-pattern/

🎯 ثبت‌نام عمومی برای ورکشاپ Goal-Oriented Software Architecture (GOA) شروع شده است.

همانطور که قبلاً اشاره شد، این کارگاه دو روزه با تمرکز بر حل چالش‌های پیشرفته DDD Plus برگزار می‌شود و به شما کمک می‌کند تا:

🟣 یاد بگیرید چطور معماری سیستم را از «اهداف واقعی» شروع کنید.
🟣 به جای تئوری، روی چالش‌های پیچیده و واقعی کار کنید و تجربه کسب نمایید.

ظرفیت این دوره به صورت حضوری و محدود است.

📅 مدت: دو روز — ۱۶ ساعت آموزشی. تاریخ 27 و 28 شهریور 1404

👥 اگر برنامه‌نویس، معمار نرم‌افزار، مدیر محصول یا CTO هستید، این کارگاه برای شما مفید می‌باشد.

برای اطلاعات بیشتر و ثبت‌نام، از طریق لینک زیر اقدام کنید:
https://evand.com/events/masoud-bahrami-goa-workshop

برای آشنایی عمیق‌تر با مفاهیم، می‌توانید مقاله‌های زیر را مطالعه کنید:

🧠 Goal-Oriented Architecture: https://masoudbahrami.com/article/introducing-goal-oriented-software-architecture/
❓DDD Plus Challenges: http://domaindrivendesign.ir/tag/ddd-plus/


منتظر دیدار شما در این ورکشاپ کاربردی هستیم.

نقطه | جایی که هر چیز آغاز می‌شود.
سلام دوستان عزیز و گرامی ✨

می‌خواهیم از «نقطه» بگیم.
نه یک نقطه‌ی ساده؛ بلکه نقطه‌ای که آغازگر همه چیز است.
نقطه‌ای که برای نویسنده اولین واژه است، برای نقاش اولین ضربه قلم‌مو و برای ما برنامه‌نویس‌ها، اولین خط کد.
همان جرقه‌ای که از دلش معماری‌ها، محصول‌ها و مسیرهای بزرگ ساخته می‌شوند.

ما باور داریم:
هر ایده‌ای از یک نقطه شروع می‌شود.
یک نقطه در ذهن، یک نقطه روی تخته سفید، یک نقطه در اولین commit.

نقطه، جایی برای گردهم‌آیی ماست.

جایی برای هم‌فکری، برای بازگشت به اصول و برای کشف کردن. جایی که از یک نقطه، یک مسیر می‌سازیم و از یک ایده، یک جامعه‌ی پویا.

به‌زودی با اولین برنامه میایم، تا اولین نقطه‌ی این مسیر رو با هم بگذاریم.
👀 منتظر خبرهای بعدی باشید...

Noghteh | A point to begin, to think, to build

هر مسیر بزرگ با یک نقطه کوچک شروع می‌شود…

در صفرمین جلسه نقطه، مسعود بهرامی یک سخنرانی کوتاه با عنوان "نقطه‌ی صفر" ارائه می‌دهد.

در ادامه برنامه:
- گفت‌وگوی آزاد با شرکت‌کنندگان
- پرسش و پاسخ
- برداشت‌ها و نکات کلیدی برای آغاز مسیر

📅 زمان: سه‌شنبه، 19:00 – 20:15 (به وقت تهران)
📍 آنلاین
🔗 ثبت‌نام در Luma
📖 اطلاعات بیشتر: صفحه رویداد

برنامه از 30 دقیقه دیگه آغاز میشه. منتظر دیدن و شنیدن شما عزیزان هستیم😍

What if you could refactor a codebase by starting with the end in mind❓
Refactoring doesn't have to be a blind journey 🗺️.

My latest article Backward Refactoring introduces a new mindset for large code changes. Learn to use your tests and compiler as a blueprint, guiding you from the ideal end state back to reality, one safe step at a time. It’s a method for turning a chaotic refactor into a series of deliberate, low-risk steps.

🔸The Backward Refactoring Approach in a Nutshel:

Backward Refactoring is a strategic mindset for tackling big code changes. Instead of starting with the current, messy code, you begin with the end in mind. The core idea is to first write the ideal, clean code you want to have.

This ideal code will immediately produce a cascade of compiler errors. These errors are not failures; they are your most valuable guideposts. Each error points to a specific part of the legacy code that needs to be refactored. This transforms an overwhelming project into a clear, step-by-step roadmap, allowing you to make small, safe changes while your tests act as a continuous safety net. It’s like solving a puzzle by starting with the finished picture and working backward.

Read Part 1 and start thinking backward. 👇
https://masoudbahrami.com/article/backward-refactoring-a-new-approach-for-big-code-changes/

Is Mathematics Invented or Discovered?

Silvia Jonas, Professor of Philosophy at the University of Bamberg, shares her answer:👇
Watch here

At first glance, this may seem like a silly overly simple or even irrelevant question especially for software engineers or product people. But for me the curiosity behind it goes much deeper. For me It’s not just about passing time by watching a video on YouTube on maths problems, it’s about following a question that has fascinated people for centuries.

------
Here’s what I keep asking myself:
🔵 Why has this question survived history? If it didn’t matter why do we still ask it after thousands of years?

🔵 Where did it start? Did someone just wake up and wonder Is math invented or discovered? Or was it born from frustration trying to explain something and stumbling upon this puzzle?

🔵 Is there even a provable answer? Or is it like asking about the meaning of life always open, never settled?

🔵 What’s at stake? How does it affect science, philosophy, or our view of reality, depending on whether math is invented or discovered?

🔵 Universality: If math is invented why does it describe the universe so precisely? If discovered where exists it before we find it?

🔵 Creativity vs. discovery: When a mathematician proves a theorem is she creating something new like a painter or uncovering something always there like an explorer?

🔵 Levels of invention/discovery: Could it be both? Numbers invented relationships discovered? Does that distinction hold?

🔵 Mind vs. reality: Is math a product of the human brain or is it embedded in reality regardless of us?

🔵 Impact on truth: If invented, is mathematics arbitrary? Could we invent it differently and still build airplanes, algorithms, or AI?

🔵 Philosophical gateway: Doesn’t this question lead to even deeper ones: What is reality? What is knowledge? What is truth?
----
🙆 Why should software engineers care?
Sometimes, the most valuable skill isn’t finding the answer it’s asking the right questions and thinking deeply. Fundamental questions even if abstract or seemingly unrelated train us to explore problems challenge assumptions and see hidden connections. Often spending time understanding the question is more important than rushing to an answer.
------

That’s why I love this question. It starts small nvented or discovered?, but quickly grows into a journey across history science philosophy and even the way we think about software.

اولش شاید این سوال خیلی ساده یا حتی بی‌ربط به نظر بیاد مخصوصا برای ما برنامه‌نویس‌ها و آدمای محصول، ولی برای من داستانش خیلی عمیق‌تر از این حرفاست. دیدن و دنبال کردن این جور پرسش‌ها فقط پر کردن وقت آزاد نیست و کمک می‌کنه ذهن کنجکاو و فعال‌تری در مواجه با مسائل داشته باشم

من به شخصه اینا رو از خودم می‌پرسم

🔹 چرا این سوال هنوز زنده‌ست؟ اگه مهم نبود چرا بعد این همه سال هنوز بحثش داغه؟
🔹 اصلا از کجا شروع شد؟ یه نفر همین‌جوری یه روز از خواب بیدار شد و پرسید ریاضی اختراع شده یا کشف؟ یا وسط یه مشکل علمی گیر کرده بود و این سوال براش پیش اومد؟
🔹 اصلا جواب قطعی داره یا مثل معنای زندگی همیشه باز می‌مونه؟
🔹 اینکه جواب چی باشه چه تاثیری روی علم، فلسفه یا حتی نگاه ما به واقعیت میذاره؟
🔹 اگه ریاضی اختراعه چرا اینقدر دقیق جهان رو توضیح میده؟ اگه کشفه، قبل از کشف کجا بوده؟
🔹 وقتی یه ریاضی‌دان یه قضیه رو ثابت میکنه داره یه چیز تازه می‌سازه مثل یه هنرمند، یا یه چیز از قبل بوده رو پیدا میکنه مثل یه کاشف؟
🔹 شاید بعضی بخشاش اختراعه، بعضیاش کشف. این مرزبندی اصلا معنی داره؟
🔹 ریاضی ساخته ذهن ماست یا توی خود واقعیت جا خوش کرده؟
🔹 اگه اختراعه، یعنی می‌تونستیم یه ریاضی دیگه اختراع کنیم و بازم هواپیما، الگوریتم و هوش مصنوعی داشته باشیم؟
🔹 این سوال در نهایت در رو باز نمی‌کنه به سوالای خیلی بنیادی‌تر؟ مثل اینکه واقعیت چیه، دانش چیه، حقیقت یعنی چی؟

و خب چرا برای ما مهندسای نرم‌افزار مهمه؟ چون خیلی وقتا مهم‌تر از جواب، خود سوال پرسیدنه. اینکه یاد بگیریم عمیق فکر کنیم، فرضیات رو به چالش بکشیم و ارتباط‌های پنهان رو ببینیم. حتی بعضی وقتا خود سوال مهم‌تر از جوابه. و مهمتر اینکه گاهی برخی سوالات، کلید باز شدن دریچه‌ای به سوی سوالات مهمتری و کلیدی‌تره. گاهی سوالات درست تاثیر بیشتر نسبت به پاسخ‌های دقیق دارند.

همین باعث میشه این سوال برام جذاب باشه. خیلی کوچیک شروع میشه: اختراع یا کشف؟ ولی به یکباره سوالات مهمتری رو توی ذهنم باز می‌کنه

🔹 ویدئوی جدید منتشر شد! 🔹

📌 موضوع: "مقدمه‌ای بر معماری نرم‌افزار"

در این ویدئو 40 دقیقه‌ای به موارد زیر پرداختم:

🔹چرا خیلی از نرم‌افزارها بعد از مدتی فرو می‌پاشن
🔹تفاوت بین کدنویسی و معماری
🔹یک مثال واقعی: سیستم سفارش غذای آنلاین
🔹مشکل اساسی تفکر CRUD
🔹معماری چندبُعدی: ساختار، رفتار، کیفیت‌ها، تکامل، تیم‌ها و ارتباطات
🔹و اینکه چطور تصمیم‌های امروز می‌تونن آینده سیستم رو بسازن یا خراب کنن

🎥 لینک تماشا در یوتیوب:
👉 https://www.youtube.com/watch?v=X9rd9hh4-DU&t

اگر به توسعه نرم‌افزار، معماری، یا طراحی سیستم علاقه داری، این ویدئو می‌تونه دیدگاهت رو عوض کنه.

سلام به همگی دوستان👋

اگر در رویداد نقطه‌ی صفر همراه ما بودید، می‌دانید که آغاز یک مسیر چقدر حیاتی است. حالا وقت آن است که به یکی از مهم‌ترین چالش‌های این مسیر بپردازیم: بدهی فنی.

در دنیای مهندسی نرم‌افزار، بدهی فنی (Technical Debt) اغلب به عنوان کد شلخته یا غیراصولی شناخته می‌شود؛ اما آیا واقعاً به همین سادگی است؟

مسعود بهرامی در دومین رویداد نقطه با ارائه‌ای با عنوان بدهی فنی: فراتر از کد، فراتر از استعاره، دیدگاه شما را نسبت به این مفهوم تغییر خواهد داد. در این رویداد، بررسی می‌کنیم که چطور بدهی فنی فراتر از کد است و چرا باید از این استعاره ساده فاصله بگیریم تا به درک واقعی از تأثیر آن بر پروژه‌ها و سازمان‌ها برسیم.

بعد از ارائه، فرصت برای گفت‌وگوی آزاد فراهم است. این بهترین زمان برای به اشتراک گذاشتن تجربیات و سؤالات شماست.


جزئیات رویداد
سخنران: مسعود بهرامی

📅 زمان: سه‌شنبه 1 مهرماه 1404، 19:00 – 20:30 (به وقت تهران)
📍 آنلاین
📖 اطلاعات بیشتر: ثبت‌نام در Luma

منتظرتان هستیم تا با هم به عمق این موضوع برویم و دیدگاه‌هایمان را به اشتراک بگذاریم.

خلق از دلِ لحظه

خلق کردن برای من، مرز نمی‌شناسد. نه در بند صفر و یک می‌ماند و نه در فاز کوانتوم و نه در نت‌های موسیقی. این بداهه‌نوازی آماتور، مانند یک ایده‌ی نرم‌افزاری درخشان، از دلِ یک آن بی‌برنامه متولد شد؛ لحظه‌ای که فقط به ندای درونم گوش دادم و گذاشتم جاری شوم.

نرم‌افزار و موسیقی، هر دو یک زبان واحد دارند: زبانِ خلق در لحظه. جایی که تمرین‌های پنهان، ناگهان به یک اثر تبدیل می‌شوند و هر اشتباه، پله‌ای برای رسیدن به کمال می‌شود. این قطعه‌ی کوچک، حاصل ترکیب یکسری عوامل آماتور با یک نوازش آماتور سه‌تار است، که برآیندش هم آماتور است. اما امیدوارم به دلِ شما بنشیند

ببینید و بشنوید👇🏻
https://youtu.be/LurNrEjGhsY

🎥 چهارمین ویدئوی مجموعه‌ی شش بُعد معماری نرم‌افزار توی یوتیوب منتشر شد.

🌀 معماری نرم‌افزار خیلی بیشتر از کُد و نموداره.

اون چیزی که یه سیستم رو زنده می‌کنه و زنده نگه می‌داره، رفتارشه: جریان‌ها، تعاملات، تصمیم‌ها و واکنش‌هایی که توی عمل اتفاق می‌افتن. همین‌طور انتظاراتی که از سیستم یا محصول داریم. در واقع، انتظارات ما همون رفتارهاییه که از سیستم انتظار داریم ببینیم.

متافور کلاسیک برای نرم‌افزار، جعبه‌ی سیاهـه: ورودی میره داخل، پردازش انجام میشه، و خروجی همون چیزی میشه که ما به‌عنوان رفتار سیستم تجربه می‌کنیم.

توی این ویدئو در مورد بُعد رفتاری مختصرا صحبت کردم. جایی که معماری واقعی، خودش رو نشون میده.
اینکه سیستم چطور تغییر می‌کنه، چه ریتمی داره، چطور با محیط درگیر میشه، و تصمیم‌های معماری چطور روی تجربه‌ی کاربر و کیفیت نهایی تاثیر میذارن.

اگه معماری رو فقط به ساختار و اجزا محدود کنیم، نصف داستان از دست میره.
ولی وقتی رفتار رو بفهمیم، تازه میشه سیستمی ساخت که نه فقط کار کنه، بلکه رشد کنه، سازگار بشه و پایدار بمونه.

📌 ویدئوی کامل رو ببینید:
https://www.youtube.com/watch?v=KBOk_f0f9ow

سلام به همگی
اولین روز پاییزتون بخیر و شادی باشه🍂🍁

نیم‌ساعت دیگه شروع می‌کنیم

🎥 سومین! ویدئوی مجموعه‌ی شش بُعد معماری نرم‌افزار توی یوتیوب منتشر شد

سلام به همگی، پاییزتون رنگی و قشنگ باشه بدور از خبرهای بد! 🍁🍂

معماری نرم‌افزار فقط رسم جعبه و خط نیست! 🤯

در قسمت سوم از مجموعه شش بُعد معماری نرم‌افزار، به بُعد حیاتی ساختاری (Structural Dimension) پرداختم.

فونداسیون یک سیستم، بر اساس اهداف و تصمیمات کلیدی ساخته می‌شود. این بُعد، به چگونگی شکل‌گیری شالوده یک سیستم، اجزای آن و روابط میان‌شان می‌پردازد. اینجا جایی است که معماری واقعی خودش را نشان می‌دهد، جایی که تصمیمات ما در مورد ساختار سیستم، بر عملکرد، مقیاس‌پذیری و پایداری آن تأثیر مستقیم می‌گذارند.

در این ویدیو می‌تونیم ببینیم که:

🔹چرا معماری، فراتر از کد و نمودارها است.
🔹چطور انتخاب‌ها و تصمیمات ساختاری، بر تمام جوانب یک سیستم تأثیر می‌گذارند.
🔹چگونه با درک کامل بُعد ساختاری، می‌توان معماری‌هایی ساخت که نه تنها کارآمد باشند، بلکه توانایی رشد و سازگاری با آینده را نیز داشته باشند.

شش بعد معماری نرم‌افزار اضلاع مهم، حیاتی و مکملی هستند که من برای یک انتخاب معماری صحیح نرم‌افزار معرفی کردم. در هر ویدئو بصورت مختصر به هر کدام از این ابعاد پرداخته خواهد شد.

✅ برای تماشای ویدیو و درک عمیق‌تر این بُعد مهم، همین حالا کلیک کنید:
https://www.youtube.com/watch?v=faQUQ63kIDo

🔴 بدهی فنی: یک استعاره‌ی خسته! چرا باید به جای Technical Debt از System Debt بگیم؟

حقیقت اینه که مشکل فقط کد نیست؛ تصمیم‌های عجولانه‌ی کسب‌وکاری، ساختارهای ناکارآمد و فرهنگ تیمی و سازمانی هم بدهی می‌سازن.

در ارائه‌ام در آخرین رویداد "نقطه" توضیح دادم که دیگه نمی‌تونیم از اصطلاح Technical Debt استفاده کنیم. این استعاره رنگ خودش رو باخته و نمی‌تونه واقعیت پیچیده‌ی سیستم‌های نرم‌افزاری رو توصیف کنه.
من همیشه از اصطلاح مناسب‌تری به اسم بدهی سیستمی (System Debt) استفاده کردم. به دلایل زیر من همیشه از این واژه استفاده می‌کنم:

🔹 مسئولیت مشترک
بدهی فقط مربوط به تیم توسعه نیست. همون‌طور که در مقاله‌ام نوشتم:

Calling it technical makes it sound like only developers are responsible. Debt often comes from business decisions, cultural habits, or organizational structures.

میتونیم بگیم بدهی سیستمی یک چتر بزرگ‌تره که همه‌ی بدهی‌های فنی، سازمانی و فرهنگی رو در بر می‌گیره.

🔹استراتژی در مقابل ریسک
مدیریت بدهی نباید یک اتفاق تصادفی باشه؛ باید یک تصمیم آگاهانه باشه.

"The key is intentionality. Conscious debt is strategy. Unconscious debt is risk."

بدهی سیستمی اصطلاح جامع‌تریه که همه‌ی این عوامل رو زیر یک چتر میاره. و مدیریت آگاهانه‌اش می‌تونه بزرگ‌ترین مزیت رقابتی شما باشه.

مقاله کامل رو از لینک زیر می‌تونید بخونید 👇🏻
https://masoudbahrami.com/article/technical-debt-more-than-code-more-than-a-metaphor/

🎥 ویدئو جدید: Technical Debt Is a LIE Introducing System Debt؟

اغلب وقتی از بدهی فنی (Technical Debt) صحبت می‌کنیم، همه‌چیز رو گردن کد و توسعه‌دهنده‌ها می‌ندازیم.
اما واقعیت اینه که ریشه‌ی مشکل معمولاً در جای دیگه‌ست، تصمیم‌های سازمانی، فرهنگ تیمی، و فشارهای بیزنسی.

توی این ویدئو، بر اساس مقاله‌ی من، توضیح می‌دم چرا باید به جای بدهی فنی از مفهوم بدهی سیستمی (System Debt) صحبت کنیم و چطور این مفهوم و این دیدگاه می‌تونه کمک کنه که پایه محکم و بهتری جهت بررسی بدهی‌های یک محصول برای مدیرها، PMها و تیم‌های فنی بوجود بیاد.

🔹 موضوعات کلیدی:

🔵 بدهی فنی فقط نوک کوهه یخه
🔵 بدهی سازمانی و فرهنگی، عامل اصلی فرسایش تیم‌هاست
🔵 چطور تصمیم‌های بیزنسی، توسعه‌ی نرم‌افزار رو بدهکار می‌کنن
🔵 گام‌هایی برای ساخت تیم‌هایی که بدهی رو آگاهانه مدیریت می‌کنن

📺 تماشا در یوتیوب:
👉 https://www.youtube.com/watch?v=TYQq5plYNyM

📖 متن کامل مقاله:
👉 https://masoudbahrami.com/article/technical-debt-more-than-code-more-than-a-metaphor/

رویداد دوم نقطه:
چطور تصمیم‌ها در تیم شما گرفته می‌شوند؟

تصمیم‌گیری در تیم‌های نرم‌افزار و محصول فقط انتخاب بین گزینه‌ها نیست؛ ترکیبی از قدرت، فرهنگ و تعامل نقش‌هاست.
در این گفت‌وگوی جمعی آنلاین، با هم درباره‌ی فلو تصمیم‌گیری، نقش عنوان‌ها، همکاری تیم‌ها و صدای مشتری و جونیورها صحبت می‌کنیم.

📌 سؤالات برای بحث:

🔹 تصمیم‌ها در تیم شما از کجا شروع می‌شوند و چطور به نتیجه می‌رسند؟
🔹 نقش عنوان‌ها و موقعیت‌ها (مثل مدیر محصول، لید فنی، مدیرعامل...) در تصمیم‌گیری چقدر پررنگ است؟
🔹 آیا صدای افراد جونیور یا تازه‌وارد در تصمیم‌ها شنیده می‌شود؟
🔹 همکاری بین تیم‌های محصول، فنی و طراحی در تصمیم‌سازی چه نقشی دارد؟
🔹 جای مشتری یا استفاده‌کننده نهایی در تصمیم‌گیری تیم شما کجاست؟
🔹 آیا فیدبک نقشی واقعی در تصمیم‌گیری‌ها دارد یا صرفاً جمع‌آوری می‌شود؟

🗓 سه‌شنبه ۲۹ مهرماه ۱۴۰۴ | 🕖 ۱۹:۰۰ تا ۲۰:۳۰
💻 آنلاین

🔗 ثبت‌نام: https://luma.com/0zeu5bn1

سلام به همگی عزیزان و همراهان گرامی✋
ساعت 19:00 برنامه شروع میشه، بی‌صبرانه منتظر دیدن و شنیدن شما هستیم

رویداد سوم نقطه:
با موضوع: Clean Product

در فضای توسعه نرم‌افزار فارغ از نقش و عناوین افراد، این موضوع جا افتاده است که باید کد تمیز بنویسیم؛ خوانا، قابل نگهداری، زیبا.
اما خب متاسفانه کمتر کسی در مورد محصول تمیز صحبت کرده، یا حساس بوده 🤔

نرم‌افزار می‌تونه از نظر فنی بی‌نقص باشه، اما از درون پرایراد و کثیف، پر از هدف‌های مبهم، تصمیم‌های پراکنده و چراهای فراموش‌شده. اتفاقا تصور می‌کنم این سناریو را خیلی از ماها تجربه کرده باشیم!

مفهوم Clean Product یعنی بازگرداندن وضوح، هدف و یکپارچگی به چیزی که می‌سازیم، نه فقط به نحوه‌ی ساختنش.
اما تعریف Clean این‌جا ساده نیست؛ بدون context درست و مناسب Clean Product نمی‌تواند make sense کند

در این سخنرانی، مسعود بهرامی از زبان، تصمیم‌ها و نیت‌هایی می‌گوید که تمیزی واقعی یک محصول را شکل می‌دهند، و دوگانگی میان Clean Code و Clean Product به‌عنوان فرمول یک محصول موفق را معرفی می‌کند

این رو از من داشته باشید که:

محصول زمانی تمیز است که تصمیم‌هایش معنا داشته باشند، نه فقط کدهایش

🗓 سه‌شنبه ۲۹ مهرماه ۱۴۰۴
🕖 ساعت ۱۹:۰۰ تا ۲۰:۳۰
💻 آنلاین

🔗 ثبت‌نام: https://luma.com/qc2yhog5