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