نوشته های حسین مولائی

جداسازی نگرانی ها از طرح حل مسئله یا DDD؟

حسین مولائی — Mon, 25 May 2026 21:10:19 +0330

در این مقاله به بحث اصلی جداسازی نگرانی ها به وسیله DDD (اریک ایوانز) و حل مسئله (problem solving)می پردازیمهمیشه در ساخت هر برنامه ای (وب ، بازی ، بومی (native)) باید توجه داشته باشیم که در سال های قبل از 2000 نیستیم و در عصر کاهش هزینه ها هستیم، اما در عصر حاظر این امر باعث پیچیدگی هایی در تولید نرم افزار ها شد همچنین توهم تکنلوزی گرایی (لبه تکنولوژی) حرکت کردن باعث میشود بیزنس ها در همان شروع (قسمت فنی) شکست بخورند یا هزینه های زیادی را به کسب کار ها تحمیل کنند.در قسمت (separation of concerns) جداسازی نگرانی ها نیز همینطور است. اما راه حل چیست؟ساده ببینیمزمانی که می خواهیم یک برنامه را تحلیل کنیم برای ساخت یا توسعه مانند یک پروژه ساده آن را جداسازی کنیم مثلا قسمت User ، Accounting در تحلیل حل مسئله آن ها را جدا کنیم در بیشتر مواقع نیازی به باندد کانتکس (DDD) نیست، این نیاز به تجربه دارد اما بهتر در این مرحله شما تصور کنید چیز از DDD نمیدانید و یک پروژه خیلی ساده می خواهید بسازید در این مرحله جداسازی عادی حل مسئله پاسخ گو شما هستبیزنس صحبت میکندزمانی که پروژه بزرگ باشد، بر اساس تجربه ما آن را درک میکنیم و این جا با یک جداسازی عادی روبه رو نخواهیم بود به طور مثال : آلیس از حساب خود پولی به حساب باب انتقال میدهد، در صحبت خیلی ساده هستاما موقع نوت برداری اگر عملیات شکست بخورد؟ یا اگر سرعت اینترنت آن را در صف (kafka and etc) قرار دهد چی؟ سرویس یوزر باید آن را مدیریت کند یا سرویس حساب ها؟ آیا لایه بندی سیستم نیاز است (داشتن معماری)؟قطعا مثال بالا یک بخش کوچک از یک سیستم بزرگتر بود که خودش جدا شده بود و باز هم نیاز به جدا سازی برای کاهش نگرانی ها درون آن حس میشود. در این موقعیت ها تصمیم تیم و مدیر تیم (team lead) باید به سمت باندد کانتکس باشد زیر پروژه خیلی بزرگ تر هست و حل مسئله هر بخش یا هر سرویس کوچک تر است از اصل مسئله پس اینجا با روش حل مسئله ساده نگرانی ها جدا نمیشوندنگاه بالا به پایینبطور کلی در دوره ای هستیم که اول نباید تولید کنیم و بعد به بیزنس وصل کنیم، باید بیزنس را درک کرده و بعد با توجه به نیازمندی آن تولید کنیم ، اضافه تر یا کم تولید کردن هر دو به بیزنس هزینه وارد میکنند.برای جداسازی نگرانی ها هم برای اینکه از تولید اضافی یا کم جلوگیری کنیم بهتر است، نگاه بالا به پایین داشته باشیم اول بیزنس را درک کنیم و بعد نگرانی ها را جدا کرد.سایت کفاشی آشنا ----> حل مسئلهسیستم پرداخت حقوق شرکت کولر سازی ----> DDDاین روش دید از بالا بسیار موثر هست میتواند از هزینه اضافه برای سیستم های بزرگ جلوگیری کندنتیجه گیریبطور کلی بهترین روش برای جداسازی نگرانی ها چه در سطح کد چه در سطح بیزنس نگاه بالا به پایین بهتر استهمچنین با درک بیزنس خیلی بهتر میشود مسیر توسعه را درک کرد تا اینکه از طریق کد به سطح بیزنس برسیم. برای پروژه های بزرگ بیزنس خودش به ما میگه نگرانی ها را چگونه جدا کنیم و در بیزنس های کوچک تر نیز با روش حل مسئله می شود این کار را انجام داد.

اصول SOLID از دیدگاه رابرت سی. مارتین

حسین مولائی — Tue, 17 Feb 2026 18:50:46 +0330

اصل مسئولیت واحد (SRP)به گفته عمو باب، اصل مسئولیت واحد (SRP) تنها زمانی می‌تواند به درستی اعمال شود که شما به وضوح بازیگران سیستم را شناسایی کنید."یک ماژول باید در برابر یک و فقط یک بازیگر مسئول باشد."گاهی اوقات، بهترین راه برای اثبات یک اصل، بررسی این است که وقتی آن نقض می‌شود چه اتفاقی می‌افتد.بیایید به یک مثال رایج نگاه کنیم:متد calculatePay() توسط بخش حسابداری تعریف و استفاده می‌شود که به مدیر ارشد مالی گزارش می‌دهد.متد reportHours() توسط بخش منابع انسانی استفاده می‌شود و به مدیر ارشد عملیات گزارش می‌دهد.متد save() توسط مدیران پایگاه داده، تحت نظر مدیر ارشد فناوری مدیریت می‌شود.در نگاه اول، ممکن است به نظر برسد که این کلاس از SRP پیروی می‌کند. به هر حال، هر متد یک کار واحد دارد. اما در واقعیت، این نقض آشکار SRP است. چرا؟زیرا قرار دادن این سه متد در یک کلاس واحد، سه بازیگر مختلف را به هم متصل می‌کند - به این معنی که تغییرات یک تیم ممکن است ناخواسته بر سایر تیم‌ها تأثیر بگذارد.⚠️ یک سناریوی واقعیتصور کنید که هر دو تابع calculatePay() و reportHours() یک متد کمکی به نام regularHours() را به اشتراک بگذارند.این متد ممکن است مانند یک تابع مسئولیت واحد به نظر برسد. اما اگر بخش حسابداری بخواهد نحوه محاسبه اضافه کاری را تغییر دهد، چه اتفاقی می‌افتد؟ آنها regularHours() را برای رفع نیازهای خود تغییر می‌دهند.اما مشکل اینجاست: منابع انسانی نیز از regularHours() استفاده می‌کند - و از این تغییر آگاه نیستند. تیم حسابداری آزمایش‌های خود را انجام می‌دهد و همه چیز خوب به نظر می‌رسد. اما چند هفته بعد، منابع انسانی شروع به شکایت از گزارش‌های نادرست می‌کند.زمانی که مشکل کشف می‌شود، سازمان ممکن است از داده‌های نادرست و تصمیمات نادرست رنج برده باشد.SRP به ما می‌گوید که با تفکیک مسئولیت‌ها بر اساس عامل، می‌توان از این مشکل جلوگیری کرد.👨‍💻 هرج و مرج توسعه موازیحالا تصور کنید دو توسعه‌دهنده روی این کلاس کار می‌کنند:یکی calculatePay() را برای تیم مالی به‌روزرسانی می‌کند.دیگری reportHours() را برای منابع انسانی به‌روزرسانی می‌کند.وقتی زمان ادغام فرا می‌رسد، آنها با تداخل مواجه می‌شوند - با وجود اینکه ابزارهای کنترل نسخه مدرن کاملاً پیشرفته هستند، تداخل‌های ادغام در کلاس‌های مشترک هنوز خطرناک هستند و می‌توانند اشکالات ظریفی ایجاد کنند.✅ طراحی بهتریک راه حل عملی، جداسازی داده‌ها از رفتار است. به جای یک کلاس بزرگ Employee، مسئولیت‌ها را تقسیم می‌کنید:PayCalculator منطق حقوق و دستمزد را مدیریت می‌کند.HoursReporter ساعات کاری را مدیریت می‌کند.EmployeeRepository با پایداری سروکار دارد.همه این کلاس‌ها می‌توانند به یک ساختار EmployeeData مشترک دسترسی داشته باشند - یک نگهدارنده داده ساده بدون هیچ منطق تجاری.هر کلاس فقط شامل کد منبع لازم برای مسئولیت خود است. آنها از یکدیگر آگاه نیستند و احتمال همپوشانی تصادفی یا اتصال ناخواسته را کاهش می‌دهند.برای مشاهده تصویر در اندازه کامل، اینتر را فشار دهید یا کلیک کنید💡 نمای بیرونی به کمک شما می‌آیدممکن است اعتراض کنید: "حالا من سه کلاس برای نمونه‌سازی و ردیابی دارم!"منصفانه است. یک رویکرد رایج در اینجا استفاده از الگوی نما است - یک کلاس واحد که پیچیدگی زیرسیستم را پنهان می‌کند و یک رابط کاربری ساده‌شده به دنیای خارج ارائه می‌دهد.برای مشاهده تصویر در اندازه کامل، اینتر را فشار دهید یا کلیک کنیدبنابراین برنامه شما با یک کلاس سروکار دارد، اما در زیر کاپوت، مسئولیت‌ها از هم جدا می‌مانند.🧠 نکات پایانیاصل مسئولیت واحد باید نه تنها در سطح متد، بلکه در کل معماری - از بالا به پایین - اجرا شود.هر بازیگر در سیستم باید یک کلاس مربوطه داشته باشد، با متدهای متمرکز که فقط نیازهای آن بازیگر را برآورده می‌کنند. این منجر به سیستمی می‌شود که مقیاس‌پذیری، آزمایش و نگهداری آن آسان‌تر است.

🧠 چگونه از سردرگمی در برنامه‌نویسی دست برداریم و پیشرفت واقعی داشته باشیم

حسین مولائی — Tue, 10 Feb 2026 19:20:08 +0330

نقشه راهی برای مبتدیانی که از گزینه‌های زیاد احساس سردرگمی می‌کنند✍️ مقدمه: منابع بسیار زیاد، وضوح بسیار کمما در دنیایی زندگی می‌کنیم که منابع برنامه‌نویسی نامحدود هستند - از ویدیوهای یوتیوب و دوره‌های Udemy گرفته تا کتاب‌ها، مستندات و حتی ابزارهای هوش مصنوعی مانند ChatGPT.اما این فراوانی اغلب منجر به سردرگمی می‌شود. بسیاری از ما به مصرف‌کنندگان منفعل محتوا تبدیل می‌شویم، بدون اینکه بفهمیم کجا هستیم و به کجا می‌رویم. من هم همین اشتباه را کردم. فکر می‌کردم تماشای آموزش‌های بیشتر باعث می‌شود بهتر و سریع‌تر شوم. اما حقیقت این است: تبدیل شدن به یک برنامه‌نویس به تماشای آموزش‌ها مربوط نمی‌شود - بلکه به درک و ساختن آن مربوط می‌شود.در هر شغلی، صبر، تلاش و پشتکار ضروری است - و فناوری اطلاعات نیز از این قاعده مستثنی نیست. یادگیری کدنویسی و رسیدن به اولین شغل ممکن است بسته به عوامل مختلفی از 6 ماه تا 3 سال طول بکشد:1.موقعیت مکانی شما2.روش یادگیری شما3.فناوری‌هایی که انتخاب می‌کنید4.مربی که دنبال می‌کنید...و موارد دیگر🧩 اشتباهی که شما را عقب نگه می‌داردشاید شما با زبان‌های سطح بالا مانند پایتون یا جاوا اسکریپت شروع کرده‌اید. این اشتباه نیست - اما ممکن است شما را از ساختارهای عمیق‌تر برنامه‌نویسی دور کند.بدون درک عمیق از ساختارهای داده، الگوریتم‌ها و مدیریت حافظه، کدنویسی سطحی می‌شود. در نهایت خسته می‌شوید یا گیر می‌کنید.🧠 فقط زبان مهم نیست — بدانید می‌خواهید چه کسی باشیدقبل از اینکه یک زبان یا مسیر یادگیری را انتخاب کنید، از خود بپرسید:آیا می‌خواهید یک کارمند تمام وقت باشید یا یک فریلنسر؟آیا می‌خواهید فقط کد بنویسید یا به عنوان یک معمار نرم‌افزار، سیستم‌های کامل طراحی کنید؟آیا از کار تیمی لذت می‌برید یا ترجیح می‌دهید به تنهایی کار کنید؟این سؤالات به شما کمک می‌کنند تا مسیر خود را شکل دهید. به عنوان مثال، اگر هدف شما فریلنسری است، شاید جاوا اسکریپت و وردپرس کاربردی‌تر از الگوریتم‌ها باشند. اما اگر می‌خواهید مهندس نرم‌افزار شوید، باید اصول و معماری را درک کنید.باید بدانید که به ماشینی که هیچ درکی ندارد، دستورالعمل می‌دهید - باید آن را گام به گام راهنمایی کنید.💻 سی پلاس پلاس یا پایتون: با کدام شروع کنیم؟هر دو نقاط قوت خود را دارند، اما اگر می‌خواهید حافظه، ساختارهای داده و عملیات سطح پایین را درک کنید، سی پلاس پلاس این عمق را به شما می‌دهد.بیایید به یک مقایسه ساده نگاه کنیم:🔹 مثال سی پلاس پلاس:int numbers[5] = {1, 2, 3, 4, 5}; cout << numbers[2]; // Output: 3در اینجا، شما دقیقاً می‌دانید چه اتفاقی می‌افتد: یک بلوک از حافظه برای ۵ عدد صحیح اختصاص داده شده است. شما نوع داده و ساختار حافظه را کنترل می‌کنید.🔹 مثال پایتون: numbers = [1, 2, 3, 4, 5] print(numbers[2]) # Output: 3ساده‌تر است، اما جزئیات حافظه و نوع داده کلیدی را حذف می‌کند. برای نتایج سریع عالی است، اما برای درک عمیق مناسب نیست.اگر این مثال برای شما معنی ندارد، نگران نباشید - فقط به کلمه کلیدی int توجه کنید.در زبان‌های با نوع پویا، شما به صراحت انواع داده را تعریف نمی‌کنید. این راحت است، اما درک واقعی نحوه مدیریت داده‌ها در حافظه را دشوارتر می‌کند - که می‌تواند باعث مشکلات طولانی مدت شود.📚 منابع پیشنهادی مناگر می‌خواهید درست شروع کنید و اصول اولیه قوی بسازید، پیشنهاد می‌کنم:کتاب «چگونه با ++C برنامه‌نویسی کنیم» نوشته‌ی دیتل - برای یادگیری ++C و ساختارهای داده از ابتدا عالی است.کتاب «کد تمیز» نوشته‌ی رابرت سی. مارتین - به شما کمک می‌کند پس از یادگیری اصول اولیه، کد تمیز و قابل نگهداری بنویسید.این کتاب‌ها برای ساختن طرز فکر و تفکر مانند یک برنامه‌نویس عالی هستند. اما به یاد داشته باشید: آن‌ها فقط ۲۰٪ از مسیر هستند. ۸۰٪ دیگر تمرین و پشتکار خودتان است.🛠 مسیر یادگیری گام به گام من🔸 مرحله ۱: مفاهیم اولیه کامپیوترIDE چیست؟ زبان برنامه‌نویسی چیست؟ کد چگونه اجرا می‌شود؟🔸 مرحله ۲: یادگیری C++ (یا یک زبان سطح متوسط مشابه)با کتاب Deitel شروع کنیدآرایه‌ها، حلقه‌ها و اشاره‌گرها را تمرین کنید🔸 مرحله ۳: به ساختار داده‌ها و الگوریتم‌ها بپردازیدلیست‌های پیوندی، پشته‌ها، صف‌ها و درخت‌ها را تمرین کنیدپیچیدگی زمان و مکان را بیاموزید🔸 مرحله ۴: اصول کد تمیز و SOLID را بیاموزیدنحوه نوشتن کد قابل نگهداری و خوانادرک معماری تمیز و نظم کدنویسی🔸 مرحله ۵: ساخت پروژه‌های واقعی و همکاریایجاد یک پروژه ساده مانند یک برنامه To-Do یا یک سیستم مدیریت دانش‌آموزاستفاده از Git و GitHub برای کنترل نسخه🎯 نتیجه‌گیریدر برنامه‌نویسی، سرعت مهم نیست - درک مهم است.شاید به سرعت به هدفتان برسید، یا شاید (مثل من) عجله نکنید، اشتباه کنید و عمیقاً رشد کنید. در هر صورت، مهم این است که مقصدتان را بشناسید.اگر الان احساس گم شدن می‌کنید، این مقاله نقشه راه شماست.مسیر درست را انتخاب کنید، منابع مناسب را انتخاب کنید، عمیقاً پیش بروید - و هرگز تمرین را متوقف نکنید.