سلام به همگی عزیزان
داریم برای لایو آماده میشیم. 🫰

با تشکر از همه عزیزانی که در لایو شرکت کردند.❤️

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

در نهایت هم لطفا فیدبک خودتون رو هم مطرح کنید این باعث میشه برنامه‌های بعدی خیلی بهتر طراحی و اجرا بشوند.


🟡🔴همانطور که جلسه قبل هم اشاره شد، همانند طرحی که سال گذشته اجرا کردیم، اگر تصمیم گرفتید EDD رو توی تیم خودتون اجرا کنید، می‌تونید پیام بدید، که در حد ۱-۲ جلسه، کارگاه رو براتون به عنوان facilitator برگزار کنیم. این اجرا هزینه‌ای برای شما نخواهد داشت.

دو نوع ورکشاپ متفاوت در Exploratory Domain Discovery وجود دارد:

ورکشاپ Discovery-Time EDD: این نوع برای مدلسازی فضای مسئله در یک دومین پیچیده استفاده می‌شود.

ورکشاپ Design-Time EDD: این ورکشاپ برای فاز طراحی و ترسیم مرزهای تفکیک دومین کاربرد دارد.

در رویداد زنده‌ی امروز، تمرکز ما بر Design-Time EDD بود. در این جلسه، چند رهیافت معرفی و بررسی شدند که می‌توانند در فرآیند Design-Time EDD مفید واقع شوند. این رهیافت‌ها به صورت خلاصه در زیر آمده‌اند:

🔵 Heuristic 1 – Invariants Define Boundaries
مرزها(خواه در سطح یک سرویس باشند و خواه در سطح طراحی یک AR) جایی ایجاد می‌شوند که یک قاعده همیشه باید برقرار باشد.

🔵 Heuristic 2 – Events Connect, Not Shared Data
مرزهای Bounded Context‌ها باید از طریق رویدادها با هم ارتباط برقرار کنند، نه با اشتراک داده‌ها یا جداول.

🔵 Heuristic 3 – High-Churn Areas Should Be Separate
بخش‌هایی از دومین که تغییرات زیادی دارند بهتر است در باوندد کانتکست جداگانه‌ای قرار بگیرند.

🔵 Heuristic 4 – Model the Rules First, Not the Data
ابتدا با قواعد کسب‌وکار شروع کنید و سپس داده‌ها را اضافه کنید. در غیر این صورت، Aggregate حجیم و ناکارآمد خواهد شد.

🔵 Heuristic 5 – Focus on Flow of Value (Not Components)
پرسش کنید: ارزش کجا ایجاد، تبدیل و تحویل داده می‌شود؟

🔵 Heuristic 6 – Each Aggregate Protects Only One Critical Consistency Rule
یک Aggregate که چندین قاعده‌ی حیاتی را اعمال کند، Aggregate شکست خورده‌ای است(تصحیح می‌کنم :)).

🔵 Heuristic 7 – Domain Circular Pattern: Finding Natural Boundaries

🔵 Heuristic 8 – Ubiquitous Language: Why Words Matter

برای مطالعه‌ی کامل‌تر و جزئیات بیشتر درباره‌ی Design-Time EDD، می‌توانید به لینک‌های زیر مراجعه کنید:
🔹 Introducing Design-Time EDD

🔹 EDD Heuristics for Design-Time

🔵 Clean Code Mastery – Advanced Software Craftsmanship Workshop


در سال‌های اخیر، بسیاری از تیم‌ها با رشد پروژه و اضافه‌شدن فیچرها، به‌جای سرعت بیشتر، با کدهای سنگین، سخت‌خوان، پر از بدهی فنی و توسعه‌پذیری پایین روبه‌رو شده‌اند. از Refactorهای پرهزینه گرفته تا باگ‌هایی که در ساده‌ترین تغییرات ظهور می‌کنند.

تقریباً تمام تیم‌ها در نقطه‌ای از مسیر توسعه، با یک حقیقت تلخ روبه‌رو می‌شوند:
مشکل اصلی، زبان برنامه‌نویسی یا تکنولوژی‌ها نیست، کیفیت کدی است که هر روز تولید می‌شود. حتی در حضور و ظهور AI.

⚪️ ویژگی‌های کلیدی دوره:
🔹آموزش عملی Clean Code، Refactoring، Design Principles و معماری تمیز
🔹تمرین‌های واقعی روی کدهای Legacy
🔹شناسایی و حذف Code Smellها در پروژه‌های واقعی
🔹کارگروهی، Code Review، PR Workflow و تحلیل مشکلات واقعی تیم‌ها
🔹آشنایی با معماری‌های Clean/Hexagonal و رویکرد DDD در سطح کاربردی
🔹یادگیری TDD، Unit/Integration Testing و طراحی Evolvable Code


📅ساختار دوره:
۵ جلسه تخصصی × ۴ ساعت
یک جلسهٔ Hands-on عملی + Q&A

برای جزئیات کامل و ثبت‌نام:
🔗domaindrivendesign.ir

🌟 رویداد پنجم نقطه:
شفافیت در کار تیمی: چطور بگوییم چه می‌خواهیم؟
نقطه به ایستگاه ششم خود (ایندکس پنجم!) رسید.

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

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

🗓 تاریخ: سه‌شنبه، 25 آذر ۱۴۰۴
🕖 زمان: ۱۹:۰۰ – ۲۰:۳۰
💻 مکان: آنلاین(لینک رویداد برای افراد بعدا ارسال خواهد شد)

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

سلام به همگی👋
برنامه در حال شروع هست

خیلی خیلی ممنون و سپاسگزارم از همه بچه هایی که اومدن و نظراتشون رو شیر کردند. خیلی جلسه خوبی بود. می‌طلبه یه جلسه دیگه رو هم کمی مشخص‌تر باز به همین موضوع بپردازیم

🍉✨ شب یلداتون مبارک ✨🍉

صحبتِ حُکام، ظلمتِ شبِ یلداست
نور ز خورشید جوی، بو که برآید


امشب،
شبِ موندنِ نور در دلِ تاریکیه
شبِ قصه، انار،
و صبری که به صبح ختم می‌شه.

امید که این شب بلند،
با دل‌های روشن،
خنده‌های گرم
و امید به فردایی روشن‌تر
به خیر و خوشی بگذره 🌱

یلداتون پر از مهر و روزهاتون کوتاه از غم 🍀

مکتب‌خانه DDD
https://news.1rj.ru/str/DomainDrivenDesign_ir

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

ما هم چند سال پیش در یکی از پروژه‌ها دنبال ساختن چارچوبی مشابه بودیم؛ مدلی که تیم‌ها بدون قضاوت بتونن بفهمن سرویس‌شون دقیقاً کجاست و چه چیزهایی باید بهبود پیدا کنه. تا حدی هم موفق بود، اما تجربه‌ی اجرا نکات جالبی داشت

سخت‌ترین و دارک‌ترین بخش همین context-aware تصمیم‌گیری بود، نه لزوما تعریف متریک‌ها برای حرکت سرویس‌ها توی لایه‌های مدل(اولش فکر میکردیم سخترینش تعریف و اعمال و پیاده‌سازی متریک‌هاست بعد دیدم واقعا ساده‌تر از چیزی که فکرش رو میکردیم و چالش اصلی جای دیگه است) بلکه فهمیدن و وزن‌دهی نقش واقعی هر سرویس توی بیزنس بخصوص برای کسب‌و‌کاری که دائما در حال تغییر و رفع باگ و افزودن فیچر جدید. اما context-aware کردن کل مدل، اونقدر پیچیده و nuanced بود که گاهی کل فرآیند رو فلج می‌کرد

خواسته یا ناخواسته توی اسکیل بزرگ ابزارها به‌مرور نقش کریتیکالی پیدا می‌کنند بدون اینکه کسی از قبل براشون نقشه‌ای چیده باشه و رفتار واقعی سیستم همونی که باید سنجیده بشه، لابه‌لای بالا و پایین شدن سرویس‌ها توی مدل گم می‌شد. اوبر هم تجربه‌ای زیسته از همین جنس داشت به اسم Service Maturity Index

​یه چالش دیگه که ما مستقیم کمتر باهاش درگیر شدیم ولی تو اسکیل بالا ناگزیره، نرخ sampling واسه سنجش صحت و سلامت هر سرویس برای تصمیم‌گیری داده‌محوره. سرویس‌های rate بالا، دیتای زیادی تولید می‌کنن و پرفورمنس توشون حیاتیه برا همین sampling می‌ره روی عددایی مثل ۰.۰۰۱٪. بر اساس دیتای ذخیره‌شده همه‌چیز خوبه، اما در عمل لزوماً این‌طور نیست. اینجا باید مراقب بود که آمار تبدیل به فکت نشن

توی Software Engineering at Google هم به تجربه مشابهی اشاره شده که آخرش می‌گه بلوغ‌های این‌جوری چون جنسشون استانداردسازیه و استانداردسازی یعنی محدودیت (و برای بعضی‌ها اجبار)، بهتره بر اساس outcomeها مثل کاهش MTTR سنجیده بشه که کار سختیه واقعا!

مارتین فاولر هم یه نوشته کوتاه داره به اسم The Maturity Model Fallacyکه میگه مدل‌ها اگر از کمک به گام بعدی تبدیل بشن به رتبه‌بندی ضد خودشون عمل می‌کنن.

​چالش دیگه توی تجربه من، فشار وحشتناک روی زیرساخت و ops بودش و خب بالاخره این فشار خودش رو توی قالب تجربه و بد اسمل‌های دیگه خودش رو نشون میده و میزنه بیرون. در حالی که تیم dev یا وقت نمی‌کرد توازن بین خروجی بیزنس و متریک‌ها رو تنظیم کنه یا چند سرویس به ارث رسیده بهش بود، یا اصلا سرویس‌های بی‌صاحب بودن :) که کسی از وجودشون خبر نداشت! context-aware نبودن اینجا هم دردسر می‌ساخت. بعدا فهیمیدم اسپاتیفای مدل جالبی رو پیش گرفته برای این سناریوها به اسم اسپاتیفای رویکرد golden paths

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

🔹معیارهای امتیازدهی ما
برای هر سرویس، این بُعد‌ها رو امتیاز می‌دادیم (ترکیب بیزنسی + فنی + سازمانی):

1- حیاتی بودن بیزنسی: core مثل پرداخت/جستجو/قیمت‌گذاری/کد تخفیف/پیشنهاد محصول یا حاشیه‌ای! وزنشون توی revenue/user journey چقدره
2- حجم/نوع ترافیک: read-heavy/mixed، latency-sensitive؟ downtime چقدر UX رو می‌زنه؟
3- موقعیت در dependency graph: failureش چند سرویس دیگه رو می‌ندازه؟ golden path کاربر ازش رد می‌شه؟
4- هم‌خوانی استک: مثلا با talent سازمان مچ می‌شه؟ learning curve/bus factor چقدر ریسکیه؟ تکنولوژی یه زبونی نباشه که هیشکی توی سازمان بلدش نیست، علی‌رغم اینکه خیلی هم تکنولوژی یا زبان برنامه نویسی خوبی هم براش انتخاب شده
5- مالکیت تیمی: تیم مشخص/توانمند داره یا ارثیه/بی‌صاحب؟😁 incidentش چند تیم رو درگیر می‌کنه؟ شعاع تاثیرش یا radius effectاش چقدر.
6- فرآیند dev: deploy frequency/rollback readiness، وابستگی به افراد کلیدی، end-to-end ownership؟

و نهایتا کنار این‌ها یا بهتره بگم بر اساس اینها MTTD/MTTR، deploy failure rate، alert quality، observability رو اضافه می‌کردیم. ترکیبشون نشون می‌داد کجا ارزش داره سرمایه‌گذار (ن)کنیم

معرفی الگوی طراحی نرم‌افزار Behavior as Data

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

جهت حل مشکل بالا، من الگوی طراحی Behavior as Data رو معرفی کردم که کمک می‌کنه بتونیم بر همچین سناریوهایی غلبه کنیم.

این الگو بصورت کلی به ما این امکان رو میده که متوجه بشیم چه موقع یک فیلد ساده یا مقادیر یک enum بهتره تبدیل بشن به یک مدل مشخص دیتایی و رفتاری.

توی مقاله یکسری هیوریستیک و نشانه که به توسعه‌دهنده و افراد محصولی کمک می‌کنه به این موضوع پی ببرند به همراه مثال‌های واقعی ارایه شده


https://www.linkedin.com/pulse/introducing-behavior-data-pattern-masoud-bahrami-qc2cf