کتاب های برچسب domain-driven-design
تاریخ: ۱۷:۵۰:۳۳ ۱۳۹۵/۱۰/۲۳ پنج شنبه
توسط: MotoMan
امتیاز: ۱
برچسب ها: Domain-Driven-Design | Design Patterns |

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

 

تعداد بازدید: ۷۱۸
دیدگاه ها: ۰
تاریخ: ۱۲:۶:۸ ۱۳۹۴/۵/۲۱ چهارشنبه
توسط: MotoMan
امتیاز: ۱۱
برچسب ها: Domain-Driven-Design | Design Patterns |

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

تعداد بازدید: ۲۱۹۵
دیدگاه ها: ۰
تاریخ: ۲۰:۱۶:۴۷ ۱۳۹۳/۹/۲۵ سه شنبه
توسط: MotoMan
امتیاز: ۷

الگوها، Domain Driven Design(DDD) و Test Driven Development (TDD) معمارها و توسعه دهندگان نرم افزار را قادر می‌سازد تا سیستم هایی قدرتمند و استوار و قابل نگهداری بسازند. اکنون یک راهنمای جامع و عملی برای به کارگیری تمامی این تکنیک‌ها با تمرکز بر محیط Microsoft .NET وجود دارد. مباحث موجود در این کتاب برای توسعه دهندگان جاوا نیز مفید است.

تعداد بازدید: ۲۹۲۱
دیدگاه ها: ۰
تاریخ: ۰:۶:۲۹ ۱۳۹۳/۶/۱۳ پنج شنبه
توسط: MotoMan
امتیاز: ۲
برچسب ها: Domain-Driven-Design |

(Domain-driven design (DDD بر مواردی که در برنامه‌های سازمانی اهمیت دارد تمرکز می‌کند از جمله حوزه‌ی کسب کار اصلی. با استفاده از اصول شی گرایی، شما می‌توانید مدل دامنه را توسعه دهید که همه اعضای تیم از جمله متخصصان کسب و کار و متخصصین فنی آن را درک کنند.حتی بهتر از آن این است که این مدل مستقیما با پیاده سازی زیربنایی برنامه ارتباط دارد.
با این حال اگر تا به حال سعی کرده باشید که یک برنامه Domain-Driven بسازید حتما متوجه شده اید که پیاده سازی اصول DDD از گفتن آن‌ها آسان‌تر است. N.a.k.e.d objects، یک فریمورک متن باز به زبان جاوا است که به شما این امکان را می‌دهد تا با نوشتن کلاس‌های اصلی دامنه یک برنامه کارا بنویسید. N.a.k.e.d objects، به صورت خودکار اشیای دامنه شما را در نمایش دهنده‌های عمومی و یا حتی HTML نمایش میدهد. شما می‌تواندی از یکپارچگی اش با test-drive استفاده کنید و توسعه برنامه خود را به صورت story-by-story انجام دهید. و در نهایت وقتی که کار توسعه برنامه به اتمام رسید، می‌توانید برنامه را به صورت کامل بر روی موتور اجرایی N.a.k.e.d objects اجرا کنید و یا بر روی زیر ساخت کنونی برنامه‌ی خود اجرا کنید.

تعداد بازدید: ۱۵۷۴
دیدگاه ها: ۰
تاریخ: ۱۰:۱۷:۱۳ ۱۳۹۳/۵/۲۲ چهارشنبه
توسط: MotoMan
امتیاز: ۱۱
برچسب ها: Domain-Driven-Design | Design Patterns |

وقتی که بچه بودم، پدرم خلبانی هواپیما‌های کوچک را یاد گرفته بود. اغلب کل خانواده می‌توانستند به پرواز بروند. گاهی اوقات ما برای ناهار به فرودگاه دیگری پرواز می‌کردیم و پس از آن بر می‌گشتیم. وقت هایی که پدر وقت کمی داشت ولی دلش برای پرواز تنگ می‌شد، دوتایی بیرون می‌رفتیم و چرخی دور فرودگاه با مانور نشستن و بلند شدن مجدد می‌زدیم.
ما همچنین سفرهای طولانی نیز با هم داشتیم. برای آن سفر‌ها ما همیشه نقشه ای از مسیر که پدر زودتر ترسیم کرده بود داشتیم. وظیفه‌ی ما بچه‌ها این بود که تا با نگاه کردن به نشانه‌های مسیر زیرمان به مسیریابی کمک کنیم تا بتوانیم مطمئن بمانیم که در مسیر قرار داریم. این برای ما تفریح فوق العاده ای بود چرا که شناسایی اشیا با آن فاصله زیاد کار شناسایی آن‌ها را سخت می‌کرد. در واقع من مطمئن بودم که پدرم همیشه می‌دانست الان کجا هستیم. او تجهیزات زیادی روی داشبورد خود داشت و برای کار با آن‌ها گواهینامه گرفته بود.
منظره از هوا واقعا دیدگاه من را تغییر داد. گهگاه من و پدرم بر روی خونه در حومه شهر پرواز می‌کنیم. از چند صد پا بالاتر، دیدی از خانه به من می‌دهد که قبل از آن نداشتم. وقتی که پدر از روی خانه می‌گذشت، مادرم و خواهر هایم به سمت حیاط می‌دویند و دست برایمان تکان می‌دادند. من می‌دانستم که آن‌ها چه کسانی هستند با این که نمی‌توانستم در چشم هایشان نگاه کنم. ما نمی‌توانستیم صحبت کنیم. حتی اگر از پنجره هواپیما هم فریاد می‌زدم احتمالا کسی صدای من را هم نمی‌شنید. من می‌توانستم نرده هایی که ملک ما را از جاده جدا کرده بودند را ببینم. و حیاط بزرگی آن جا بود که تابستان با ماشین چمن زنی بر روی آن دوری می‌زدم. از آسمان من فقط دریای سبز می‌دیدم نه تیغه‌های ماشین چمن زنی را.
من عاشق آن لحظاتی بودم که در آسمان بودم. این‌ها خاطراتی بودند که در ذهنم حک شده اند. به همان اندازه که آن عاشق آن پرواز‌ها بودم، مطمئنا جایگزینی برای بودن روی زمین وجود نداشت و همان اندازه که برایم با حال بودند ولی آن فرود آمدن‌ها و تیکاف کردن‌ها خیلی کوتاه بودند تا احساس روی زمین بودن بهم دست دهد.
کار کردن به صورت (Domain-Driven Design (DDD مثل پرواز کردن برای یک تازه کار به نظر می‌رسد. منظره از آسمان حیرت انگیز است؛ اما گاهی اوقات بعضی چیز‌ها آن قدر نا آشنا به نظر می‌آیند که برای گم کردن راه کافی است. در واقعیت رفتن از نقطه‌ی A به نقطه‌ی b خیلی دور به نظر می‌رسد. بزرگترهای DDD به نظر میرسید که همیشه می‌دانند که کجا هستند. آن‌ها از مدت‌ها پیش، نقشه ای را طرح ریزی کرده اند و کاملا با تجهیزات جهت یابی خود در تماس هستند.  خیلی‌های دیگر احساس می‌کنند که فرود نیامدند. چیزی که احتیاج هست، توانایی فرود آمدن است. در آخر هم احتیاج به یک نقشه داریم که ببینیم به کجا هستیم و کجا باید برویم.
در کتاب Implementing Domain-Driven Design به شما کمک می‌کنم تا DDD را پیاده سازی کنید و مثال‌های زیادی با استفاده از ابزارها و تکنولوژی‌ها آشنا ارائه داده شده است. در ادامه شما در مورد معماری‌ها و الگو‌های جایگزین برای یکپارچه کردن  چندین مدل دامنه توضیح داده شده است تا شما بتوانید از آنها استفاده کنید.

 

تعداد بازدید: ۲۶۳۳
دیدگاه ها: ۴
تاریخ: ۱۱:۳۳:۱۸ ۱۳۹۳/۵/۲۰ دوشنبه
توسط: MotoMan
امتیاز: ۶
برچسب ها: Domain-Driven-Design | Design Patterns |

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

تعداد بازدید: ۳۰۳۰
دیدگاه ها: ۰
تاریخ: ۱۱:۴۵:۴۸ ۱۳۹۲/۱۰/۲۳ دوشنبه
توسط: sooth3r
امتیاز: ۱۸
برچسب ها: WPF | MVVM | Domain-Driven-Design | Design Patterns |

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

در این کتاب نه تنها با پترن MVVM آشنا می‌شوید بلکه در راه رسیدن به این موضوع نویسنده شما را با انواع وجه‌های مختلف در ساخت یک برنامه‌ی تجاری آشنا و آماده خواهد کرد!

تعداد بازدید: ۳۴۹۲
دیدگاه ها: ۶
تاریخ: ۱:۱۳:۲۷ ۱۳۹۲/۴/۱۲ چهارشنبه
توسط: MotoMan
امتیاز: ۱۳

زمانی که اولین نسخه‌ی Entity Framework را منتشر کردیم، به طور مداوم بازخورد هایی را از طرف جامعه‌ی DDD)Domain-Driven-Design) ، در مورد مواردی که  در EF  فراموش کرده ایم، دریافت می‌کردیم. مشکلات اصلی که باعث عدم عملکرد DDD با EF می‌شدند شامل مواردی مانند فقدان persistence ignorance support ، مشکلات تست پذیری و اصطکاک زیاد در بعضی نواحی API ، بودند.

اعضای جامعه DDD و تیم EF، زمان قابل توجهی را صرف بحث و  تبادل اطلاعات  در مورد این موضوعات و پتانسیل واقعی EF کرده اند. این کار تاثیر بسیار زیادی بر روی نسخه‌ی دوم EF که EF 4.0  نامیده می‌شد، و بهینه سازی هایی که بعد‌ها  در EF 4.1 شکل گرفتند  و شامل بهبود‌های عظیمی برای حل آن نگرانی‌ها بود، گذاشت.

EF هنوز هم رشد می‌کنه تا تجربه کار را بهبود بخشیده و رسیدن به "گودال موفقیت" را در توسعه نرم افزار سهولت بخشد. اما اکنون در EF 4 ما هم اکنون به نقطه‌ی عطفی رسیده ایم؛ وقتی که مشتریان، EF را برای استفاده در برنامه هایشان انتخاب می‌کنند؛ آن‌ها معمولا از ما در مورد Best Practice‌ها سوال می‌کنند، برای مثال: چگونه برنامه هایمان را با نگهداری بالا و کمترین کد بنویسیم.بیشتر مشتری‌های ما ، مفاهیمی مانند Persistence Ignorance و تست پذیری  را برای اولین بار در فروم ها، بلاگ‌ها و کنفرانس‌های ما یاد می‌گیرند!  بنابراین ما همیشه به دنبال راهی برای منتشر کردن این اطلاعات هستیم.

تعداد بازدید: ۲۸۱۷
دیدگاه ها: ۰
loading...

لطفا منتظر بمانید...