Language-Driven Design

In the realm of software development, we assert that software systems are fundamentally rooted in language. The Language-Driven Design (LDD) approach emphasizes that:

a clear and shared language is paramount for creating systems that are not only effective but also easily understandable and adaptable to change.

🧠 Clarity over Complexity

We prioritize simplicity in communication, which leads to greater understanding among team members and stakeholders. By avoiding jargon and convoluted terminology, we make our systems more accessible and reduce the possibility of misunderstandings that can hinder progress.

💬 Language Unites Teams

A common vocabulary fosters collaboration and strengthens team dynamics. When teams speak the same language, they can collaborate more efficiently, share knowledge effectively, and align their efforts towards common goals, resulting in improved productivity and innovation.

🧱 Architecture Reflects Language

The structure of our systems should mirror the language we use to describe them. A well-designed architecture based on a shared language not only enhances comprehension but also facilitates maintenance and future development. This alignment enables developers to iterate quickly and respond to changing requirements with confidence.

🔁 Language Evolves with Reality

We acknowledge that both language and systems are dynamic and must evolve as our understanding and needs change. By fostering a culture of continuous learning and adaptation, we can ensure that our language and designs remain relevant and effective in addressing real-world challenges.

Introducing (Domain)Language-First Architecture

Imagine an architecture where the very language of your domain is the foundation upon which your software is built. This is the core principle of Language-First Architecture. As you can see in the diagrams, at the heart of LFA is Language itself. It's not just about using domain language in communication; it's about making it the blueprint for your system.

📌Introducing (Domain)Language-First Architecture

Imagine an architecture where the very language of your domain is the foundation upon which your software is built. This is the core principle of Language-First Architecture.

✅ As you can see in the diagrams, at the heart of LFA is Language itself. It's not just about using domain language in communication; it's about making it the blueprint for your system.

✅ Surrounding the Language core is the Model. Here, the domain language is transformed into concrete data structures and business rules, directly reflecting the language's vocabulary and grammar.

✅ Expanding further, we have the Context. This layer represents the environment in which the system operates, encompassing user interactions and external dependencies. It's where the language's meaning is understood within the system's real-world application.

✅ Finally, the Logic layer is the outermost shell. It's where the magic happens – where the domain language is processed and executed, driving the system's behavior.

The small squares you see represent the interaction points with the outside world – APIs, databases, user interfaces – all communicating with the system in the language it understands best.

Start with words: Use the same words your business uses every day.
Words make the rules: These words decide how the software works.

📌 چهار ضلع طراحی نرم‌افزار: زبان، مدل، متخصصان دامنه، و کد

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

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

💬 مدل‌سازی یه فرایند لحظه‌ای نیست، یه مسیر تدریجیه. وسط گفت‌وگوها شکل می‌گیره، توی برخورد با واقعیت‌ها اصلاح می‌شه، و دائم در حال تغییره. یک فرآیند Just-In-Time

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

♻️ این تعامل بین چهار ضلع طراحی نرم‌افزار — زبان، مدل، متخصصان دامنه و کد — یه چرخه‌ی بازخورد دائمی می‌سازه. چرخه‌ای که باعث می‌شه نرم‌افزار هم دقیق‌تر بشه، هم قابل نگهداری‌تر، و هم واقعاً به درد بخور.

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


http://domaindrivendesign.ir/the-four-angles-of-software-design/

تصور کنید می‌خواهید بفهمید یک سیستم حقوق و دستمزد آنلاین چطور کار می‌کند.

🟡 ایونت استورمینگ: چه اتفاقی چه زمانی می‌افتد؟ ⏰
مثل این است که یک جدول زمانی از تمام اتفاقات مهم در سیستم حقوق و دستمزد درست کنید.

⬅ تمرکز: ترتیب رویدادها.
⬅ شروع: اولین رویداد مهم چیست؟ شاید «اطلاعات کارمند ثبت شد». بعدش چی؟ «ساعت‌های کاری وارد شد». بعد چی؟ «حقوق محاسبه شد». بعد «پرداخت انجام شد».
⬅ شبیه: کشیدن یک نمودار جریان ساده از تمام مراحل کلیدی در پرداخت حقوق.


🔴 دومین استوری تلینگ: چه کسی چه کاری می‌کند؟ 👤⚙️

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

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


🟢 Exploratory Domain Discovery:
نقطه کانونی و مرکزی و هسته‌ی اصلی در مسئله حقوق و دستمزد چیست؟ 🎯

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


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

💡 در مجموع:
• ایونت استورمینگ: نشان می‌دهد مراحل پرداخت حقوق به چه ترتیبی انجام می‌شود.
• دامین استوری تلینگ: نشان می‌دهد چه کسی در فرایند پرداخت حقوق چه کاری انجام می‌دهد.
• EDD: کمک می‌کند بفهمید هدف اصلی سیستم حقوق و دستمزد چیست و مهم‌ترین بخش‌هایی که باید روی آن‌ها تمرکز کنید کدامند.

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

🔍 معرفی مختصر Exploratory Domain Discovery (EDD)

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

این رویکرد، ریشه در تفکر سیستماتیک و روایت‌محور دارد. درست مثل یک فیلم یا رمان که همه‌ی اتفاقات برای انتقال یک پیام اصلی طراحی شده‌اند، در دامنه‌ی یک نرم‌افزار هم بیشتر اجزای سیستم در خدمت یک «مفهوم کلیدی» یا همان Main Point هستند؛ چیزی که بدون آن، کل ساختار بی‌معنا می‌شود. در EDD ما تلاش می‌کنیم این نقطه‌ی مرکزی را پیدا کرده و روابط علّی و ساختارهای اطراف آن را کشف کنیم.

🌀 فرآیند اکتشاف در EDD به‌صورت چرخشی (Iterative) و عرضی (Breadth-First) انجام می‌شود. فرض کنید Main Point در مرکز یک‌سری دایره‌ی هم‌مرکز قرار دارد. در دور اول، تصویری کلی و انتزاعی از دامنه ساخته می‌شود. در دورهای بعدی، این دایره تنگ‌تر شده و وارد جزئیات بیشتری می‌شویم. این مدل‌سازی لایه‌لایه، کمک می‌کند پیچیدگی‌ها را بهتر درک کرده و رفتارهای تکرارشونده را بشناسیم.

✨ یکی از ویژگی‌های کلیدی EDD، روایت معکوس (Backward Storytelling) است — یعنی به‌جای اینکه با «از کجا شروع کنیم؟» آغاز کنیم، می‌پرسیم: «ته داستان چیست؟». این دیدگاه باعث می‌شود روابط علت و معلولی واضح‌تر و دقیق‌تر دیده شوند.


🧩 در EDD ما با سه ابزار اصلی کار می‌کنیم:

🟦 مفهوم Domain Concept: هر مفهوم کلیدی که در دامنه وجود دارد را روی یک کارت می‌نویسیم.

🔄 مفهوم Relation : رابطه‌ی بین این مفاهیم را مشخص می‌کنیم، از انتها به ابتدا.

📝 مفهوم Example : برای هر مفهوم، یک نمونه واقعی و قابل لمس می‌نویسیم تا فهم مشترک بین افراد تیم شکل بگیرد.

🎯 مثال کاربردی:

فرض کنید در حال تحلیل یک سیستم حقوق و دستمزد هستید.
از سؤال «ته داستان چیست؟» شروع می‌کنیم: مثلاً صدور فیش حقوقی خروجی نهایی است. آن را روی یک کارت مفهومی (domain concept) یادداشت می‌کنیم. سپس یک گام به عقب: فیش حقوقی حاصل محاسبه‌ی فرمول‌های حقوق است. این فرمول‌ها هم بر اساس کارکرد ماهانه‌ی کارمند محاسبه می‌شوند.
با همین روال، مفاهیم را از پایان به ابتدا کشف و یادداشت می‌کنیم. سپس روابط میان آن‌ها را (باز هم از انتها به ابتدا) ثبت می‌کنیم. در پایان، برای هر مفهوم یک مثال واقعی (concrete example) می‌نویسیم تا از درستی و شفافیت مدل اطمینان حاصل شود.

🧠 فلسفه‌ی EDD:

• بهره‌گیری از تفکر سیستماتیک و روایت‌محور
• تمرکز بر کشف تدریجی و دید کل‌نگر به دامنه
• مدل‌سازی چرخشی برای کشف رفتارهای تکرارشونده دامنه

🔁 الگوهای رایج (Patterns):

• چرخه‌های زمانی مثل حقوق ماهیانه یا فرایند رزرو
• مفهوم کلیدی (Main Point) که سایر اجزای دامنه حول آن شکل می‌گیرند
• روایت معکوس برای کشف روابط علت و معلولی

✅ در نهایت اینکه:
EDD ابزارهای ساده‌ای داره — مثل کارت‌های مفهومی و مثال — اما قدرتش در طرز فکر پشتشه: اینکه قبل از ورود به طراحی یا کدنویسی، دقیقاً بفهمیم چه چیزی را طراحی می‌کنیم و چرا.

📎 اطلاعات بیشتر:
https://exploratorydomaindiscovery.com

-انجمن DDD ایران
@DDD_Iran

بالاخره فهمیدم که Monad اونقدرها هم وحشتناک نیست! 🤔

به بیان ساده، Monad یک الگوی طراحی هست که از Category Theory وام گرفته شده و در برنامه‌نویسی، به خصوص در زبان‌های functional، برای ترکیب عملیاتی که نیاز به تغییر state دارند (و به عبارت دیگه دارای side effects هستند) به یک روش predictable، clear و declarative استفاده می‌شود.

مونادها به ما این امکان رو میدن که عملیات‌ها رو به راحتی پشت هم بچینیم، بدون اینکه نگران خطاها یا مشکلات اجرایی باشیم.

حالا سوال اینه که Monads چطور کمک می‌کنه؟ 🤔

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

ویژگی‌های اصلی Monad ✨

یک Monad معمولاً سه ویژگی اساسی دارد:

1- ویژگی return یا unit یا construct: این متد یک مقدار رو به نوع Monadic تبدیل می‌کنه. به عبارت دیگه، اگر شما یک مقدار ساده (مثل یک عدد یا رشته) داشته باشید، با استفاده از این متد می‌تونید آن رو در یک Monad قرار بدید.

2- ویژگی bind یا flatMap: این متد به شما این امکان رو می‌ده که عملیات‌هایی رو روی مقدار داخل Monad انجام بدید. bind تضمین می‌کنه که نتیجه هر عملیات همچنان یک Monad باقی می‌مونه و می‌تونید آن رو به راحتی به عملیات‌های بعدی وصل کنید.

3- ترکیب آسان با سایر عملیات‌ها: Monads به شما این امکان رو می‌دهند که چندین عملیات رو به شکلی صاف و بدون نیاز به نوشتن کد پیچیده ترکیب کنید. این امکان به‌ویژه در asynchronous programming و side effects بسیار مفید است. ⚙️


در واقع، Monads ساختارهایی هستند که می‌تونند مقادیر رو توی خودشون نگه دارند و عملیات‌های مختلف رو بر روی آن مقادیر انجام بدهند، به طوری که می‌توان از آن‌ها در شرایط مختلف مانند side effects، asynchronous بودن، و مدیریت خطاها استفاده کرد.

یه مثال ساده

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

پیاده‌سازی مثال بالا در Haskell:

data Order
= Order { orderId :: Int, product :: String, quantity :: Int }
 
checkStock:: Order -> Maybe Order
checkStock
order 
  | quantity order > 0 = Justorder
  | otherwise = Nothing
 
processPayment
:: Order -> Maybe Order
processPayment
order = Just order
 
updateOrder:: Order -> Maybe Order
updateOrder
order = Just order
 
processOrder
:: Order -> Maybe Order
processOrderorder = do
    stockChecked <- checkStock
order
    paymentProcessed <-processPayment stockChecked
    updateOrder paymentProcessed
 
main :: IO ()

main = do
    let order = Order { orderId = 1,product = "Laptop", quantity = 5 }
    case processOrder order of
        Just o  -> putStrLn $ "Order processed:
" ++ show o
        Nothing -> putStrLn"Order failed"


به نظرتون شما در زبان‌هایی مثل C# یا Java چطور می‌تونید از این ویژگی استفاده کنید؟

یکی از بهترین تعاریف و توضیحات در مورد مفهوم Monad قطعا این ویدئوی فوق‌العاده Brian Beckman هست. پیشنهاد می‌کنم این ویدئو ارزشمند رو از دست ندید
https://www.youtube.com/watch?v=ZhuHCtR3xq8

🔁 در پست قبلی گفتیم Monad چیه و چطور می‌تونه به ما کمک کنه که عملیات‌های پیچیده رو به صورت امن، خوانا و قابل پیش‌بینی اجرا کنیم—حتی وقتی با چیزهایی مثل async، side effect یا خطا سروکار داریم.
👨‍💻 حالا می‌تونیم یه ابزار واقعی رو ببینیم که برای همین موضوع توسعه دادم و این مفاهیم رو توی c# پیاده‌سازی کردم!

📦 کتابخونه‌ی Quantum.MonadicTasks یه لایبرری مینیمال و تمیز برای کار با Task<T> به شکل Monadic هست. باهاش می‌تونی:
✅ ملیات‌های async رو زنجیره‌ای و functional ترکیب کنی
✅ از متدهایی مثل .Bind(), .Map(), .Fail() و .Tap() استفاده کنی
✅ بدون try/catch شلوغ، خطاها رو مدیریت کنی
✅ کدت رو مثل do notation در Haskell بنویسی
✅ کدی قابل تست، قابل خواندن، و قابل توسعه بنویسی

📌 چند تا از امکانات مهمش:
• .Bind() برای زنجیره کردن عملیات async
• .Map() برای تغییر نتیجه بدون await دستی
• .Fail() برای تولید خطا به‌صورت monadic
• .PerformSideEffect() برای side effectهایی مثل log یا metric
• .Sequence() برای اجرای چند عملیات async باهم
• .GetResultAsync() برای گرفتن نتیجه یا throw کردن خطا

📁 یه مثال واقعی از سفارش آنلاین: بررسی موجودی، انجام پرداخت، و آپدیت سفارش… همه توی یه زنجیره‌ی امن، بدون کد اضافی یا if تو در تو!

await MonadicTask<Order>.Return(order)
    .Bind(CheckStockAsync)
    .PerformSideEffect(LogStockChecked)
    .Bind(ProcessPaymentAsync)
    .PerformSideEffect(LogPaymentSuccess)
    .Bind(UpdateOrderStatusAsync)
    .GetResultAsync();

📍 این لایبرری برای پروژه‌های واقعی و مقیاس‌پذیر طراحی شده و توی Benchmark هم عملکرد قابل قبولی از خودش نشون داده.


🔗 کدش اینجاست، خوشحال می‌شم ببینی و نظرت رو بگی:

👉 https://github.com/Quantum-Space-Org/MonadicTasks

مکتب‌خانه DDD
@DomainDrivenDesign_ir

💡 مقایسه‌ی پارادایم‌های برنامه‌نویسی — از Flow-Based تا State-Centric

در مسیر تحول برنامه‌نویسی، از تفکر flow-based با تکیه بر functionها، رفتیم به سمت ساختارهای state-centric و assignment-driven — و در این بین، شاید چیزی مهم مثل وضوح جریان داده رو از دست دادیم.

۱- Functional Programming (FP) — function-driven، flow-based

✅ توابع هسته‌ی اصلی محاسبات هستن.
✅ توابع به‌عنوان داده در نظر گرفته می‌شه؛ می‌تونه ترکیب بشه.
✅ تمرکز روی جریان صریح داده بین functionهاست.
✅ ساده، قابل پیش‌بینی، بدون state پنهان.
⚠️ مدل‌سازی سیستم‌های واقعی و stateful در این پارادایم محدودتره.

۲- Object-Oriented Programming (OOP) — state-centric، assignment-driven

✅ توابع مرتبط به‌همراه state مشترک در قالب objectها قرار می‌گیرن.
✅ باعث modularity و استفاده‌ی مجدد از کد می‌شه.
⚠️ ولی جریان هندل کردن یک سناریو implicit می‌شه — توی methodها و تغییرات داخلی state پنهانه.
⚠️ منطق حول assign و تغییر وضعیت- change state- می‌چرخه، نه حول جریان.

۳- Actor Model — agent-centric، message-driven

✅ پارادایم OOP رو یه قدم جلوتر می‌بره: objectها به agentهای مستقل تبدیل می‌شن.
✅ این agentها فقط با پیام‌های async با هم حرف می‌زنن.
✅ برای سیستم‌های concurrent و توزیع‌شده عالیه.
⚠️ اما باز هم جریان داده پراکنده و پنهانه — در زنجیره‌های پیام و actorهای جدا.
--------------------------------------

👉 در این مسیر، از flow-based logic به سمت ساختار و مقیاس‌پذیری رفتیم — ولی اغلب با هزینه‌ی از دست دادن وضوح جریان داده.

🧭 آیا می‌تونیم دوباره بین این‌ها تعادل ایجاد کنیم؟

🎯 درک عمیق control flow یکی از پایه‌های اصلی برنامه‌نویسیه. در این مقاله به بررسی تفاوت‌های بین loop و recursion پرداختم و نشون دادم که چرا این انتخاب‌ها فراتر از syntax ساده هستن و به mental models ما برمی‌گردن.

اگه شما هم تجربه‌ای در این زمینه دارید یا سوالی براتون پیش اومده، حتماً تو کامنت‌ها باهام به اشتراک بذارید. خوشحال میشم نظر شما رو هم بدونم .

معرفی کتاب ریاضی ارزشمند "How to Solve It" (چگونه مسئله را حل کنیم)

✍️ اثر ماندگار ریاضیدان برجسته، جورج پولیا

📖 این کتاب که در سال 1945 منتشر شد، فراتر از یک راهنمای حل مسائل ریاضی است و به یک مرجع بی‌نظیر در زمینه‌ی آموزش تفکر ساختاریافته و توسعه‌ی مهارت‌های حل مسئله در تمامی جوانب زندگی تبدیل شده است. پولیا در این اثر، با زبانی ساده و گیرا، یک چهارچوب عملی و فلسفی برای مواجهه با چالش‌ها و یافتن راه‌حل‌های مؤثر ارائه می‌دهد.

🔑 مفهوم اصلی "How to Solve It" بر پایه‌ی یک فرآیند چهار مرحله‌ای استوار است:

1️⃣ درک مسئله (Understanding the Problem):
ضروری است که مسئله به طور کامل درک شود. پولیا بر اهمیت پرسیدن سؤالات کلیدی تأکید می‌کند:

- مجهول چیست؟ (What is the unknown?)
- داده‌ها کدامند؟ (What are the data?)
- شرایط چیست؟ (What is the condition?)
- آیا امکان ترسیم شکل یا نمودار وجود دارد؟
- آیا مسئله مشابهی دیده‌اید؟
- آیا می‌توان مسئله را به بخش‌های -
کوچک‌تر تقسیم کرد؟
✅ درک صحیح مسئله، نیمی از راه‌حل است.

2️⃣ طرح‌ریزی (Devising a Plan):یافتن ارتباط بین داده‌ها و مجهول و طرح‌ریزی استراتژی. پولیا "روش‌های مکاشفه‌ای" (heuristics) را معرفی می‌کند، مانند:

- حدس زدن و آزمایش کردن (Guessing and checking)
- جستجو برای الگو (Looking for a pattern)
- رسم شکل (Drawing a diagram)
- کار کردن به عقب (Working backward)
- استفاده از مسئله‌ی مشابه (Using a related problem)
- تجزیه و تحلیل (Breaking down the problem)
- ساده‌سازی (Simplifying the problem)
💡 طرح‌ریزی یک فرآیند اکتشافی است.

3️⃣ اجرا (Carrying out the Plan):اجرای دقیق و گام به گام طرح. صبر، دقت و توجه به جزئیات مهم است. هر گام باید منطقی و صحیح باشد و آمادگی برای مواجهه با مشکلات پیش‌بینی‌نشده وجود داشته باشد.

4️⃣ بازنگری (Looking Back):
بررسی و ارزیابی راه‌حل به دست آمده برای یادگیری و بهبود. سؤالاتی که باید پاسخ داده شوند:

- آیا راه‌حل صحیح است؟
- آیا روش دیگری برای حل وجود دارد؟
- آیا می‌توان از این روش برای مسائل مشابه استفاده کرد؟
- چه درس‌هایی آموختیم؟
🧐 بازنگری به بهبود عملکرد در آینده کمک می‌کند.

🌟 اهمیت و تأثیر "How to Solve It":
این کتاب با رویکرد عملی، زبان ساده و تأکید بر فرآیند تفکر، تأثیر عمیقی بر آموزش ریاضیات و مهارت‌های حل مسئله داشته است و در زندگی روزمره، علوم، مهندسی، مدیریت و سایر حوزه‌ها کاربرد دارد. پولیا با تأکید بر پرسش‌های درست، جستجو برای الگوها، استفاده از تجربیات و بازبینی، چارچوبی قدرتمند برای توسعه‌ی تفکر انتقادی و توانایی حل مسئله ارائه می‌دهد.

📚 "How to Solve It" همچنان یک منبع الهام‌بخش برای همگان است.



https://en.m.wikipedia.org/wiki/How_to_Solve_It

🎬 ویدئو: "ذهن درخشان پولیا: هنر تدریس و حل مسئله"

کاوشی در ذهن پولیا: چگونه عمیق‌تر فکر کنیم (ویژه توسعه‌دهندگان و مالکان محصول)

اگر به دنبال ارتقای سطح تفکر و توانایی حل مسائل پیچیده در کارتون هستید، پیشنهاد می‌کنم علاوه بر خواندن کتاب How To Solve It این ویدئو جالب و ارزشمند رو هم مشاهده کنید. این ویدئو، شما را به تماشای یک کلاس درس و کارگاه با جورج پولیا، نویسنده‌ی کتاب ارزشمند "How to Solve It"، دعوت می‌کند.

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

چرا تماشای این ویدئو برای شما مفید است؟

👨‍💻 برای توسعه‌دهندگان: با مشاهده‌ی رویکرد پولیا به ساختاربندی مسائل و تشویق به تفکر مستقل برای یافتن راه‌حل، می‌توانید الگوهای ذهنی قدرتمندتری در مواجهه با مشکلات فنی ایجاد کنید. این ویدئو به تقویت تفکر تحلیلی و خلاقیت شما کمک می‌کند.

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

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

🔗 لینک ویدئو: https://www.youtube.com/watch?v=h0gbw-Ur_do&t=928s

مکتب‌خانه DDD
@DomainDrivenDesign_ir

📌 ارتباط حل مسئله به روش جورج پولیا و EDD

چند وقت پیش، داشتم کتاب ارزشمند "چگونه مسئله را حل کنیم" اثر جورج پولیا را تورق می‌زدم. جورج پولیا توی این کتاب یه چارچوب ساده ولی قدرتمند برای حل مسئله ارائه می‌ده:
1️⃣ درک مسئله: قبل از هر اقدامی، مطمئن بشیم دقیقاً با چی طرفیم.
2️⃣ طراحی نقشه: یه استراتژی ما برای رسیدن به جواب.
3️⃣ اجرای نقشه: گام به گام پیش می‌ریم و برنامه‌مون رو عملی می‌کنیم.
4️⃣ بازبینی و تعمق: بعد از حل، یه نگاه بندازیم به مسیری که طی کردیم و درس‌هایی که گرفتیم.

یک همپوشانی جالب بین این توصیه‌ها و رویکرد Exploratory Domain Discovery وجود داره.
توی EDD، اولین قدم تیم برای طراحی یه سیستم اینه که بپرسه:

"هدف نهایی این سیستم چیه؟" خودمونی‌ترش اینه که: "تهش قراره به چی برسیم و جه مسئله‌ای رو حل کنیم؟". یا به قول پولیا، "صورت مسئله رو درست بفهمیم." .

1️⃣ درک مسئله: مثلاً، وقتی داریم سیستم حقوق و دستمزد طراحی می‌کنیم، "هدف نهایی" اینه که هر کارمند بعد از محاسبه دقیق حقوقش، یک فیش حقوقی عاری از خطا کنه. این میشه نقطه‌ی کانونی ما(Main Point).

2️⃣ طراحی نقشه: بعد، درست مثل نقشه‌ی پولیا، ما از اون هدف نهایی شروع می‌کنیم به عقبگرد و کشف عواملی که بهش منجر می‌شن: ثبت ساعات کاری دقیق، فرمول‌های محاسبه‌ی حقوق، انواع کسورات و... 🗺️ این دقیقاً همون مرحله‌ی "حرکت عقب‌گرد" یا "Backward Moving" در EDD هست.

3️⃣ اجرای نقشه:در مرحله‌ی بعد، با استفاده از ابزارهایی مثل کارت‌های مفهومی برای مدلسازی، برگزاری جلسات بحث و تبادل نظر با متخصصان دامنه و ایجاد نمونه‌های واقعی، سیستم رو می‌سازیم ("اجرای نقشه"). 🛠️

4️⃣ بازبینی و تعمق: و در نهایت، فرآیند EDD شامل چندین دور اکتشاف (Discovery)، تست مدل با مثال‌های واقعی، پرسیدن سوالات برای رفع ابهامات و بازبینی مستمر مدله. این همون "بازبینی و تعمق" پولیاست که به ما کمک می‌کنه مطمئن بشیم راه‌حل درستی رو پیدا کردیم و چیزهای جدیدی یاد گرفتیم. 🔄

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

به نظر من، EDD در مواجهه با پیچیدگی‌های دنیای نرم‌افزار، همون منطق قدرتمندی رو دنبال می‌کنه که پولیا برای حل مسائل ریاضی پیشنهاد داده بود. فقط ابزارها متفاوت شدن: کارت‌های Domain Concept و ارتباطات بین این کارت‌ها به‌جای معادلات، و همکاری تیمی به‌جای کار انفرادی روی کاغذ. 🤝

اما سوال اساسی در هر دو رویکرد یکیه:

"ما واقعاً در تلاش برای حل چه مشکلی هستیم؟" 🤔


برای من EDD ادامه‌ی همون نگاه پولیاست؛ فقط این‌بار در دنیای پیچیده‌تر، مشارکتی‌تر و زنده‌ترِ طراحی نرم‌افزار.
نه معادله می‌نویسیم، نه تابع مشتق می‌گیریم. ولی همون منطق رو دنبال می‌کنیم.

یکی از شعارهای اساسی در EDD این است:

See the ending. Discover the meaning. Design with purpose

این ارتباط عمیق بین تفکر ریاضی و طراحی نرم‌افزار همیشه برام جذاب بوده.


🎯 برای اطلاعات بیشتر در مورد Exploratory Domain Discovery به لینک زیر مراجعه کنید:
https://exploratorydomaindiscovery.com/

New Article

📖 Title: Flow, State, and Communication: A Comparative Exploration of Functional Programming, Object-Oriented Programming, and the Actor Model


In this paper, I compare three of the most important programming approaches (FP, OOP, Actor Model). These paradigms have, in a way, evolved from one another.

💡 My main focus is on how each of them deals with data flow, system state, and communication between different parts.

I believe that while newer paradigms solve complexity issues better, understanding how data moves through the system has become more difficult.

چرا تخمین‌زدن سخت است، و به‌جای آن چه باید کرد❓

در توسعه محصول، اغلب تحت فشاریم که "حدس بزنیم" یک کار چقدر زمان می‌برد. سؤال رایجی مثل این:
«این تسک چند روز طول می‌کشه؟»
اما بیشتر وقت‌ها، این تخمین‌ها بیشتر از اینکه بر پایه درک واقعی باشن، روی امید و حدس بنا شدن. و وقتی کار طبق برنامه پیش نمی‌ره، که خیلی وقت‌ها هم همین‌طوره، تیم‌ها دچار استرس، عجله یا سرزنش می‌شن.

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

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

به‌جای اینکه بپرسیم «چقدر طول می‌کشه؟»، می‌پرسیم:
«چقدر این کار رو می‌فهمیم؟»
و اینو از پنج زاویه اصلی بررسی می‌کنیم:

🌟 وضوح دامنه (Domain Clarity)
آیا دقیق می‌دونیم مشکل چیه و کسب‌وکار یا کاربر چی می‌خواد؟
🔄 مثال: پیاده‌سازی فرم لاگین = واضح. طراحی سیستم قیمت‌گذاری برای ۳ منطقه با قوانین در حال تغییر = مبهم.

🌟 وابستگی‌های فنی (Technical Dependencies)
چقدر این کار به سیستم‌های دیگه یا بخش‌های حساس و قدیمی بستگی داره؟
🔄 مثال: اضافه‌کردن یک تولتیپ ساده در UI = راحت. اتصال به API قدیمی یک سیستم ثالث = پیچیده و پرریسک.

🌟 وابستگی‌های بیرونی (External Dependencies)
آیا این تسک به ورودی یا تأیید تیم‌های دیگه، تأمین‌کننده‌ها یا بخش‌هایی مثل حقوقی وابسته‌ست؟
🔄 مثال: به‌روزرسانی مستندات داخلی = مستقل. راه‌اندازی فیچری که نیاز به تأیید حقوقی و هماهنگی با تأمین‌کننده داره = وابسته.

🌟 آشنایی تیم (Team Familiarity)
آیا تیم قبلاً این‌جور کارها رو با همین ابزارها انجام داده؟
🔄 مثال: رفع باگ در اپ اصلی = آشنا. ساخت سرویس جدید با زبانی که تیم بلد نیست = ناشناخته.

🌟 هماهنگی بین‌تیمی (Cross-Team Sync)
آیا این کار رو می‌تونیم کاملاً درون تیم انجام بدیم یا نیاز به هماهنگی و تأیید از جاهای دیگه داره؟
🔄 مثال: تغییر متن دکمه = مستقل. اضافه کردن فیچری که نیاز به تأیید حقوقی، دیزاین و دیتا داره = نیازمند هماهنگی بالا.

با امتیاز دادن به یک تسک بر اساس این ۵ عامل (از پیچیدگی کم تا زیاد)، درک خیلی دقیق‌تری از اونچه قراره انجام بشه به‌دست میاریم. این کمک می‌کنه بفهمیم آیا آماده اجراییم، یا باید اول کشف بیشتری انجام بدیم.

🔍 مثال واقعی:

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

- منطق قیمت‌گذاری مشخص نیست → (وضوح دامنه پایین).
- باید به سیستم یک تأمین‌کننده خارجی وصل بشه → (وابستگی زیاد).
- تیم قبلاً با سیستم پرداخت کار نکرده → (آشنایی کم).

نتیجه:

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

مکتب‌خانه DDD
@DomainDrivenDesign_ir

معرفی کوتاه الگوی طراحی State/Status Segregation Pattern

💡چرا مدل‌سازی سیستم‌ها گره می‌خورد؟ شفاف سازی Lifecycle در مقابل Context به منظور مدلسازی بهتر سیستم

تا حالا توی مکالمات کاری، مخصوصاً با مدیر محصول، به جمله‌هایی مثل این برخوردین؟

سفارش هنوز فعاله، ولی پیک تو ترافیکه، رستوران هم هنوز تأیید نکرده. تازه، کاربر زنگ زده بود آدرس رو عوض کنه."

یه جمله‌ی ساده، ولی پر از اطلاعات:
🔵 «سفارش فعال است» → یه فاز اصلی از چرخه‌ی عمر
🟠 «پیک در ترافیکه، رستوران تأیید نکرده، تغییر آدرس» → شرایط موقت و همزمان.

اینجا همون جاییه که مدل‌سازی معمول ما (با یه enum تک‌بعدی، زمخت و پربار!) به مشکل می‌خوره:

enum OrderState {
  Placed,
  Preparing,
  RiderDelayed,
  RestaurantUnconfirmed,
  AddressChangeRequested,
  Delivered
}

این مدل به‌ظاهر ساده، مفاهیم غیرمرتبط رو با هم قاطی می‌کنه:
🔴 مقدار RiderDelayed یه وضعیت گذراست، نه فاز چرخه عمر
🔴 مقدار RestaurantUnconfirmed توی مرحله‌ی آماده‌سازی معنا داره، نه بعدش
🔴 مقدار AddressChangeRequested یه رخداد کاربره، نه حالت سفارش

📍 نتیجه؟‌ مدل به ظاهر ساده، ولی گول‌زننده، شکننده، مبهم و سخت تست‌پذیر!
———

راه‌حل غلبه بر چالش متداول بالا، تفکیک "State" و "Status"
برای حل این مسئله من الگوی State/Status Segregation Pattern یا به اختصار S3 رو معرفی کردم. S3 به بیان ساده:
یه اصل مدل‌سازی که به‌وضوح بین State (فاز انحصاری و پایدار چرخه عمر) و Status (شرایط موقت، خروجی و اکشن وابسته به آن State) تمایز قائل می‌شه.

🟡 در این مدل State (حالت) یعنی کجای فرآیندیم؟
کاملا Excusive هستند و چندین مقدار State با هم Mutually Excusive نیستند. اینها حالت پایدار هر موجودیت در طراحی رو مدل می‌کنند. مقادیرشون هم باعث تصمیم‌سازی در سیستم یا توسط کاربر می‌شود. (decision driver هستند). مثلا سفارشی که در وضعیت Draft است منتظر تسویه حساب شدن توسط کاربر میمونه.

enum OrderState { Draft, Paid, Issued, Cancelled }

• فقط یکی فعاله
• تعیین‌کننده‌ی منطق اصلی سیستم


🟠 و Status (وضعیت): چه اتفاقی افتاده؟ statusها مشخص کننده context یا outcome یک state هستند. همینطور observability سیستم رو توسط اینها مدل می‌کنیم. به ازای هر state ممکن است چندین status برای آن موجودیت وجود داشته باشد. بهمین خاطر exclusive نیستند. اینها بیشتر جنبه transient دارند.

enum OrderStatus {
  RiderDelayed,
  ConfirmationSMSSent,
  AddressChangeRequested
}

• می‌تونه چندتا باشه
• فقط توصیف شرایط لحظه‌ایه، نه کنترل روند اصلی

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

نمونه واقعی:

{
  "Order": {
    "State": "OutForDelivery",
    "Statuses": ["RiderDelayed", "AddressChangeRequested"]
  },
  "Settlement": {
    "PaymentStatus": "Settled",
    "LastAttempt": {
      "Status": "Success",
      "Time": "12:03"
    }
  }
}

🧠 الگوی S3 فقط یه روش نام‌گذاری نیست؛ یه زبان مشترک برای طراحی سیستمه.
این الگو بخشی از رویکرد مدل‌سازی و طراحی من در کتابی در دست نگارش با عنوان Language-Driven Design هست. الگوی S3 کمک می‌کنه مدل‌سازی‌مون شفاف، قابل تست و قابل گسترش بشه. با جدا کردن منطق چرخه عمر از وضعیت‌های contextی، هم ساختار کد تمیزتر می‌شه، هم APIها وضوح بیشتری پیدا می‌کنن. این الگو ما رو از enumهای زمخت، متورم، تک بعدی و درهم نجات می‌ده و کمک می‌کنه سیستم‌هایی بسازیم که هم قابل فهم‌ترن، هم راحت‌تر توسعه پیدا می‌کنن.

📎 لینک مقاله‌ 👇

https://masoudbahrami.medium.com/dont-confuse-state-with-status-when-modeling-domain-601bc91f326a


مکتب‌خانه DDD
@DomainDrivenDesign_ir