دوستان خوب و عزیزم

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

امیدواریم خیلی زود، دوباره روزهای آروم(تر) و بی‌دغدغه‌تر رو به همراه آرامش تجربه کنیم 🌿❤️

💡 Mixed Responsibility Smell

فرض کنید متدی دارید که پول را به حساب کاربر برمی‌گرداند و در همان لحظه مقدار جدید موجودی را هم برمی‌گرداند:

public Money Refund(Money amount)
{
    Balance += amount;
    return Balance;
}

چرا ممکن است این کار را بکنیم❓
شاید برای سادگی، یا چون می‌خواهیم بلافاصله بعد از عملیات، موجودی جدید را در تست‌ها Assert کنیم یا آن را به کاربر نمایش دهیم. این سناریوها کاملاً معقول به نظر می‌رسند!

اما سوال اینجاست:
آیا درسته که یک متد هم وضعیت را تغییر دهد و هم مقدار به‌روز شده رو برگرداند؟ در واقع سوال مهم در باره نحوه‌ی مدل کردن و پیاده‌سازی سناریوهایی که در بالا اشاره شد، است.

در جواب باید بگم:
این دقیقاً همون جاییه که با یک Code Smell به نام Mixed Responsibility Smell روبرو هستیم.

قطعاً ما نیاز به متد دیگری داریم که صرفاً موجودی را به ما بدهد. در واقع، نمی‌توانیم برای دریافت موجودی تنها به متد Refund تکیه کنیم؛ چرا که این امر ما را مجبور می‌کند برای هر بار خواندن موجودی، یک عملیات Refund انجام دهیم که نه منطقی است و نه قابل قبول. این یعنی عملاً ما هیچ‌گاه به یک موجودی ثابت و قابل اتکا دسترسی نداریم. علاوه بر بحث عدم قطعیت (indeterministic behavior) و موارد مشابه، این وضعیت یک Code Smell جدی محسوب می‌شود. حداقل پیامد آن این است که ما یک منطق یکسان (یعنی محاسبه موجودی) را در دو نقطه مختلف تکرار می‌کنیم: هم در متد Refund و هم در متدی مانند GetBalance، حتی اگر GetBalance تنها شامل return Balance; باشد.


سوال بعدی اینه که: چرا این مشکل‌ساز است❓
این «بوی بد» زمانی اتفاق می‌افته که یک متد یا کامپوننت بیش از یک مسئولیت یا وظیفه را بر عهده بگیره و باعث شود:

♦ابهام در نقش و وظیفه اصلی کد
♦ پیچیدگی در فهم، تست و نگهداری کد
♦ تکرار منطق مشابه در چند نقطه
مثل منطق محاسبه یا به‌روزرسانی موجودی که هم در متد Refund و هم در متد GetBalance تکرار می‌شود (حتی اگر در GetBalance صرفاً return Balance; باشد)
♦ کاهش انعطاف‌پذیری و سختی توسعه کد
♦ رفتار نامعین (Indeterministic Behavior): اگر برای گرفتن موجودی مجبور باشیم همیشه Refund را صدا بزنیم، هیچ‌وقت موجودی واقعی و پایدار در اختیار نخواهیم داشت، چون هر بار با گرفتن موجودی، وضعیت تغییر می‌کند!



مثال بهتر:

// command
public void Refund(Money amount)
{
    Balance += amount; 
}

// query 
public Money GetBalance()
{
    return Balance; 
}

❇ نتیجه اینکه:
هشدار مهمی که Mixed Responsibility Smell به ما میده اینه که:

یک متد یا کامپوننت باید تنها یک مسئولیت واضح و مشخص داشته باشد.
تفکیک درست مسئولیت‌ها باعث میشه که کد:
✅ ساده‌تر و قابل فهم‌تر شود
✅ راحت‌تر تست و نگهداری شود
✅ توسعه و تغییرات آینده بدون دردسر انجام شود

To get more about Mixed Responsibility Smell follow the below link👇


https://medium.com/@masoudbahrami/mixed-responsibility-smell-18a70557b3a6

📢 Introducing Goal-Oriented Architecture
By: Masoud Bahrami, from my upcoming book Language-Driven Design

We’ve been organizing software around layers, services, and controllers for decades.

Clean Architecture, Layered, Vertical Slicing… each gives us a way to structure HOW code is written. In all cases the organization is around(mostly): how we build it!

🤔 But what if we started with why the code exists❓

That's the core of Goal-Oriented Architecture. Instead of just focusing on structure, we make the Goal the primary building block.
It becomes a first-class citizen in your architecture.

⚽A Goal is a concrete, high-level outcome your system must achieve, explicitly modeled right in your architecture.

🙋‍♂️What is Goal-Oriented Architecture about:

It isn't just about organizing code; it's about organizing intention.
It's about making your architecture a direct reflection of your business objectives, leading to clearer designs.

💸Example: TransferFunds

Imagine a TransferFunds Goal: it captures everything, preconditions, the transfer itself, and all side-effects like updating balances or sending notifications, all in one clear place. No more scattered logic!

This Goal declares:

🟥 Preconditions:

➡️ Both accounts are active
➡️ Sender has enough balance
➡️ Transfer limit isn’t exceeded

------
🟩 Goal:

➡️ Transfer funds between accounts

-----
🟨 Side-effects:

➡️ Update both balances
➡️ Log the transaction
➡️ Send notifications
➡️ Emit a FundsTransferred event

Everything related to this intent is captured in one place, the Goal, not scattered across services, handlers, and layers.

————-
🎯 The Benefits

✅ Brings business purpose to the center of your design
✅ Makes code easier to reason about, test, and trace
✅ Treats side-effects as part of the architecture, not an afterthought
✅ Encourages composable, declarative, intention-driven code
✅ Fits naturally in event-driven, DDD, and workflow-based systems

Goal-Oriented Architecture brings business purpose to the forefront, making your code easier to reason about, test, and trace.

📝 Stay tuned
Goal Oriented Architecture is a key part of my upcoming book: Language-Driven Design, A practical philosophy for designing systems that reflect how we think, speak, and solve problems. I'll talk more about it...

What does Object-Oriented Programming really mean?

the God of OOP - Alan Kay- is here to answer 👇

https://www.youtube.com/watch?v=QjJaFG63Hlo

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

تصنیف «هستی چه بود؟» روایتی‌ست از اضطراب، فرسایش و ملالی که این روزها، حتی از دل منظمات! هم به بیرون نشت می‌کند.
شعر، ساده است. اجرا، قدیمی و آماتور. حس اما، صادقانه و آشناست:
«هستی چه بود؟ قصه‌ی پررنج و ملالی...»

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

نظم هم گاهی نیاز به وقفه دارد. این، بخشی آن مکث است.


https://soundcloud.com/user-298641228/knnflitqzofw

"درک صحیح مسئله، نیمی از راه‌حل آن مسئله است."
- جورج پولیا

🧩 چگونه مسئله‌ای را به‌درستی حل کنیم؟
بر اساس روش کلاسیک جورج پولیا


⬅1. درک مسئله
پیش از هر چیز، مسئله را واقعاً درک کنید.
• مسئله از شما چه می‌خواهد؟
• داده‌های در دسترس چیست؟
• شرایط چیست و آیا این شرایط برای رسیدن به پاسخ کافی است؟ یا ناقص، متناقض، یا زائد هستند؟
• آیا می‌توانید متغیرهای مسئله را مشخص کنید؟
• آیا می‌توانید نمودار، فلوچارت یا دیاگرامی از مسئله ترسیم کنید؟

✏️ بازنویسی دقیق مسئله، اولین گام برای حل آن است.

------------------------------------------
⬅2. طراحی راه‌حل
پس از درک صحیح مسئله، به طراحی مسیر حل فکر کنید.
• آیا با چنین مسئله‌ای قبلاً مواجه شده‌اید؟
• آیا الگویی مشابه وجود دارد؟ الگوریتمی؟ راه‌حلی؟
• می‌توانید مسئله را به مسئله‌ای ساده‌تر یا آشناتر تبدیل کنید؟
• اگر اتصال مستقیمی میان داده و مجهول وجود ندارد، آیا یک مسئله‌ی فرعی یا موقت می‌تواند مفید باشد؟
• آیا امکان تغییر صورت مسئله برای قابل حل‌تر شدن آن وجود دارد؟

💡 مسائل آشنا، کلید حل مسائل ناآشنا هستند.

------------------------------------------
⬅3. اجرای برنامه
راه‌حل طراحی‌شده را گام‌به‌گام اجرا کنید.
• آیا هر گام منطقی است و بر مبنای اطلاعات درست پیش می‌رود؟
• آیا می‌توانید صحت هر مرحله را توضیح یا اثبات کنید؟
• آیا اجرای این راه‌حل به نتیجه قابل اتکا می‌انجامد؟

⚙️ اجرای دقیق، همان اندازه اهمیت دارد که طراحی دقیق.

------------------------------------------
⬅ 4 . بازنگری در نتیجه
پس از رسیدن به پاسخ، عقب برگردید و مسئله را دوباره مرور کنید.
• آیا پاسخ درست است؟
• آیا می‌توان آن را ساده‌تر یا واضح‌تر بیان کرد؟
• آیا می‌توان این روش را برای مسائل مشابه به‌کار گرفت؟
• آیا از تمام اطلاعات و شرایط استفاده شده؟

🔍 تحلیل راه‌حل، بخشی از حل مسئله است، نه مرحله‌ای اضافه.

------------------------------------------

🧠 در مجموع می‌توان گفت:
این ساختار کلاسیک، در عین سادگی، کاربردی‌ترین ابزار برای حل سیستماتیک مسائل در حوزه‌های مختلف توسعه نرم‌افزار، طراحی محصول، دیباگینگ، تحلیل داده، و تصمیم‌گیری است.

سلام دوستان عزیز 🍃
امیدوارم آخر هفته خوبی داشته باشید 🌿

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

https://MasoudBahrami.com

جایی برای ثبت و به اشتراک‌گذاری ایده‌ها، تجربیات عملی و تأملاتم درباره یافتن راه‌هایی بهتر برای توسعه نرم‌افزار بهتر.

امیدوارم مطالب سایت برای شما مفید و الهام‌بخش باشد ✨

نظرات و پیشنهادات شما برای من بسیار ارزشمند است و خوشحال می‌شوم آن‌ها را بشنوم 💬🙏

New Article: Introducing Goal-Oriented Software Architecture!

Ever feel like your software gets lost in technical details instead of focusing on what your business needs? In my new article, I introduce Goal-Oriented Architecture, a new architectural style developed to address challenges often seen in common approaches like Clean, Onion, Ports and Adapters, and Vertical Slicing architectures.

It's a fresh way to build software that puts your real business objectives, your "goals", right at the core.

Discover how it makes systems clearer, more effective, and perfectly aligned with your business vision 👇:
https://masoudbahrami.com/article/introducing-goal-oriented-software-architecture/

Have you ever been tasked with building software for a complex business process and felt like you're staring at a tangled ball of yarn?
What if you could start with the finished masterpiece and unravel it backward?

That's the aim of Exploratory Domain Discovery (EDD), a collaborative tool introduced by Masoud Bahrami.


Imagine you need to automate hotel room pricing

✅ The Desired End: The customer sees the correct final price.

🤔 Work Backward: What steps led to that price? (Discounts applied, base rate set, availability checked.)

🔄 Find Cycles: "Pricing periods" and "daily availability" are clear repeating patterns here!


By starting at the desired end result and working backward, using simple examples, EDD helps teams understand complex problems clearly. It's all about finding the main point and its surrounding details to build smarter solutions.

Math: Discovered or invented? And Why It Matters to Dev Guys❗

There's a fundamental question that has puzzled thinkers
for centuries: Is mathematics discovered, or is it invented? This long-standing debate within the philosophy of mathematics isn't just an academic exercise.

For us in software development, as designers, modelers, architects, and developers, understanding this dichotomy, and its nuances, directly impacts how we approach complex problems and build robust systems.

--------------------
✅ The "Discovered" View:
From the perspective that mathematical truths exist independently of human thought, software professionals often find themselves acting as explorers. When I delved into domains like accounting or payroll, I encountered deeply embedded principles and seemingly immutable rules.

The precise logic of financial transactions, the established principles of double-entry bookkeeping, the complex yet consistent calculations for tax liabilities or social contributions, these feel-like inherent truths governing how money and compensation work.

A big confession:
I simply discover that I'm not(and must not!) invent the principle that a debit equals a credit, or that gross pay minus deductions equals net pay.

We are accurately modeling fundamental relationships that exist independently, uncovering the mathematical structure of the real world within that domain.

--------------------
✅ The "Invented" View:
Aligned with the view that mathematics is a human-constructed system of symbols and rules we create, much of what we do in software involves invention. While the core accounting principles might be discovered, the way we implement them within a digital system is a creative act of invention. We invent abstract data structures to represent ledgers, design custom algorithms to handle intricate tax rules across different jurisdictions, or devise new abstract models for payroll processing that ensure scalability, auditability, and performance.

Example:
Consider the solution we invent for managing a large-scale accounting ledger. While debits and credits are discovered principles, the invented part is how we represent, store, and process millions of transactions efficiently in software. This involves devising custom data structures for journal entries, creating indexing strategies for rapid querying, and designing algorithms for real-time balance calculations. These aren't just paper-to-digital translations; they're new mathematical constructs and rules invented to harness computational power, ensuring consistency and performance in complex digital environments.

--------------------
✅ The Nuance of the Dichotomy:
Some philosophers, like George Lakoff, argue that this dichotomy is too simplistic, suggesting mathematics emerges from our embodied human experience. From a software professional's perspective, this nuanced view resonates strongly. We are constantly observing and discovering the underlying mathematical nature of the problem space, recognizing the inherent patterns and constraints. Simultaneously, we are inventing abstract tools, languages, and systems, from low-level algorithms to high-level architectural patterns, to articulate, solve, and extend those problems.

🧐For Example:
The recognition of recurring problems in software led to the discovery of design patterns as effective solutions. However, the formalization and naming of these patterns, along with the rules for their application, were distinct acts of invention that codified and communicated this discovered knowledge in a reusable, mathematical way.

Our work is a continuous cycle of recognizing existing mathematical structures and then creatively constructing the digital scaffolding around them.

--------------------
Understanding this dynamic, knowing when we are accurately reflecting a discovered truth versus when we are inventing a new paradigm, is crucial for making sound design decisions, ensuring system integrity, fostering innovation, and ultimately, building effective software solutions.

- Masoud Bahrami

For a long time, I struggled with complex domains like accounting and payroll. My initial mistake🙋‍♂️? Thinking I had to invent a better double-entry bookkeeping system or a new way to handle credit/debit equality.

But DDD revealed two profound truths:

🟣 Deep Understanding is Key: The more effort I invested in truly understanding the problem domain the more clearly the right solution emerged.

🟣 Needs vs. Wants: What customers or domain experts express are often just wants. My role shifted to using these wants as clues to uncover the real underlying needs.

I realized my job wasn't to reinvent established accounting principles. Instead it was to discover their true essence and the profound ideas behind them.

At the same, for modeling and designing concepts like ledge, my primary goal was to invent the best solution for them.

A financial ledger, for instance, is far more than just a simple database table separated by year; it's a rich, living concept that demands careful, accurate representation.

🎯‌ اطلاع رسانی پیش‌ثبت‌نام ورکشاپ دو‌ روزه معماری

📌‌ عنوان کارگاه: Designing Goal-Oriented Architecture
🧠‌ با تمرکز بر حل چالش‌های پیشرفته DDD Plus
📅 مدت: دو روز — ۱۶ ساعت آموزشی
👥 مناسب برای: برنامه‌نویسان، معماران نرم‌افزار، مدیران محصول و CTOها
📍 به‌صورت حضوری / ظرفیت محدود: حداکثر ۱۵ نفر

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

👇‌ اطلاعات بیشتر و ‌ثبت‌نام:
https://domaindrivendesign.ir/product/%d9%88%d8%b1%da%a9%d8%b4%d8%a7%d9%be-designing-goal-oriented-architecture-with-ddd-plus-challenges/

👇لینک مستقیم فرم پیش ثبت‌نام:
کلیک کنید

✨صبح همگی عزیزان بخیر🌱

ظرفیت پیش‌ثبت‌نام کارگاه Designing Goal-Oriented Architecture در کمتر از یک روز تکمیل شد! از استقبال شما سپاسگزاریم.❤️ 🙏

به زودی با عزیزانی که موفق به ثبت‌نام شدن تماس می‌گیریم تا مرحله بعدی رو تکمیل کنیم.

برای دوستانی هم که جا موندن: داریم بررسی می‌کنیم که بتونیم ظرفیت رو یه کوچولو بیشتر کنیم! اگه شد، همین‌جا اطلاع می‌دیم 💬👀

🚀 Need advanced date/time manipulation in .NET?

I'm excited to announce the release of Quantum.Tempo v1.0.0, a powerful, calendar-agnostic date/time framework for .NET!

🔹 Intuitive string-based API for dates, times, intervals, and durations
🔹 Supports multiple calendars: Gregorian, Persian (Shamsi), Hijri, and custom
🔹 Recurrence rules (RRULE), interval algebra, fuzzy date parsing, and timezone support
🔹 Comes with a handy REPL CLI for interactive exploration
🔹 Fully ISO-compliant and localization-ready


Check it out on NuGet:
👉 https://www.nuget.org/packages/Quantum.Tempo/

🌟 Try it, contribute, and let's make date/time handling in .NET simpler and smarter!

💡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: https://domaindrivendesign.ir/tag/ddd-plus/


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

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

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

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

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

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

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