اشتراک‌ها
فریم ورک Material UI

A CSS Framework and a Set of React Components that Implement Google's Material Design 

فریم ورک Material UI
مطالب
(Domain Driven Design) به زبان ساده
DDD چیست؟ روشی است ساده، زیبا، در وهله اول برای تفکر، و در وهله دوم برای توسعه نرم افزار، که می‌توان بر مبنای آن نیازمندیهای پویا و پیچیده‌ی حوزه دامین را تحلیل، مدل و نهایتا پیاده سازی کرد.
در این روش توسعه نرم افزار تاکید ویژه ای بر الزامات زیر وجود دارد:
  • تمرکز اصلی پروژه، باید صرف فائق آمدن بر مشکلات و پیچیدگیهای موجود در دامین شود.
  • پیچیدگیهای موجود در دامین پس از شناسایی به یک مدل تبدیل شوند.
  • برقراری یک رابطه‌ی خلاق بین متخصصان دامین و افراد تیم توسعه برای بهبود مستمر مدل ارائه شده که نهایتا راه حل مشکلات دامین است بسیار مهم می‌باشد.
مبدع این روش کیست؟
بخوانید:
Eric Evans is a specialist in domain modeling and design in large business systems. Since the early 1990s, he has worked on many projects developing large business systems with objects and has been deeply involved in applying Agile processes on real projects. Eric is the author of "Domain-Driven Design" (Addison-Wesley, 2003) and he leads the consulting group Domain Language, Inc. 
ویدیویی سخنرانی اریک اوانس با عنوان: DDD: putting the model to work
شرایط موفقیت اجرای یک پروژه مبتنی بر DDD چیست؟
  • دامین ساده و سر راست نباشد.
  • افراد تیم توسعه با طراحی / برنامه نویسی شی گرا آشنا باشند.
  • دسترسی به افراد متخصص در مسائل مرتبط با دامین آسان باشد.
  • فرآیند تولید نرم افزار، یک فرآیند چابک باشد.
در این باره چه چیزی بخوانم؟
برای شروع توصیه می‌کنم بخوانید: Domain-Driven Design: Tackling Complexity in the Heart of Software 
نویسنده: Eric Evans


در ادامه می‌پردازم به اینکه ابزار DDD برای شکستن پیچیدگیهای دامین و تبدیل آنها به مدل کدامند؟
پاسخ خلاصه در زیر آمده است. دعوت می‌کنم تا شرح هر یک از این موارد را در پستهای بعدی پیگیر باشید.
  • Entity
  • Value Object
  • Aggregate
  • Service
  • Repository
  • Factory

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

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

DDD در واقع روشی است برای دقیق‌تر فکر کردن در مورد نحوه ارتباط و تعامل اجزای مدل با یکدیگر. این سبک طراحی (DDD) به تولید مدلی از اشیاء می‌انجامد که نهایتا تصویری قابل درک (Model) از مسائل مطرح در حوزه‌ی کاری ارائه می‌دهند. این مدل ارزشمند است وقتی که:

1- نمایی آشکار و در عین حال در نهایت سادگی و وضوح از همه‌ی مفاهیمی باشد که در حوزه عملیاتی نرم افزار(Domain) وجود دارد.
2- به تناسب درک کاملتری که از حوزه کاری کسب می‌شود بتوان این مدل را بهبود و توسعه داد(Refactoring).

در DDD کوشش می‌شود که با برقراری ارتباطی منطقی بین اشیاء، و رعایت سطوحی از انتزاع یک مشکل بزرگتر را به مشکلات کوچکتر شکست و سپس به حل این مشکلات کوچکتر پرداخت.

توجه کنیم که DDD به چگونگی سازماندهی اشیاء توجه ویژه ای دارد ولی DDD چیزی درباره برنامه نویسی شی گرا نیست. DDD متدولوژیی است که با بهره گیری از مفاهیم شی گرایی و مجموعه ای از تجارب ممتاز توسعه نرم افزار (Best Practice) پیچیدگیها را و قابلیت توسعه و نگهداری نرم افزار را بهبود می‌دهد.

ایده مستتر در DDD ساده است. اگر در حوزه کاری مفهوم (Concept) ارزشمندی وجود دارد باید بتوان آن را به وضوح در مدل مشاهده کرد. برای مثال صحیح نیست که یک شرط ارزشمند حوزه کسب و کار را با مجموعه‌ی سخت فهمی از If / Else ها، در مدل نشان داد. این شرط مهم را می‌توان با Specification pattern پیاده سازی کرد تا تصویری خوانا‌تر از Domain در مدل بوجود بیاید.

مدلی که دستیبابی به آن در DDD دنبال می‌شود مدلی است سر راست و گویا با در نظر گرفتن همه جوانب و قواعد حوزه‌ی عمل نرم افزار. در این مدل مطلوب و ایده آل به مسائل ذخیره سازی (persistence) پرداخته نمی‌شود. (رعایت اصل PI). این مدل نگران چگونگی نمایش داده‌ها در واسط کاربری نیست. این مدل نگران داستانهای Ajax نیست. این مدل یک مدل Pureاست که دوست داریم حتی المقدور POCO باشد. این مدلی است برای بیان قواعد و منطق موجود در حوزه عمل نرم افزار. این قواعد همیشه تغییر می‌کنند و مدلی که از آموزه‌های DDDالهام گرفته باشد، راحت‌تر پذیرای این تغییرات خواهد بود. به همین دلیل DDD با روشهای توسعه به سبک اجایل نیز قرابت بیشتری دارد.  
اشتراک‌ها
مجموعه‌ای خلاصه شده از معرفی الگوهای طراحی برای استفاده توسعه دهندگان نرم افزار

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

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

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

🔸 همیشه منظور هر الگو را در ذهن خود مرور کنید و هنگام برخورد با یک مسئله به دنبال مناسب‌‌ترین الگو بگردید.

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

راهنمای شروع سریع برای مطالعه الگوهای طراحی 👇🏻

PDF Cards: designpatternscard.pdf

DesignPatterns-online.pdf

مجموعه‌ای خلاصه شده از معرفی الگوهای طراحی برای استفاده توسعه دهندگان نرم افزار
اشتراک‌ها
مجموعه Awesome Domain-Driven Design

A curated list of Domain-Driven Design (DDD), Command Query Responsibility Segregation (CQRS), Event Sourcing, and Event Storming resources 

مجموعه Awesome Domain-Driven Design