بیانیه‌ی توسعه چابک نرم‌افزار و ارزش‌های مطرح در آن

1. Individuals and interactions over processes and tools.

در بیانیه‌ی توسعه‌ی چابک نرم‌افزار گفته شده روشی که چابک‌کاران در توسعه‌ی نرم‌افزار پیش می‌گیرند، روشی است که در آن به «افراد و تعاملات آنها» نسبت به «فرآیندها و ابزارها» ارزش و اهمیت بیشتری داده می‌شود.
به بیانی دیگر اگر در سازمان یا تیمی ناهنجاری‌ و مشکلاتی در رفتار افراد و تعاملات آنها وجود داشته باشد، تاکید و پافشاری در اجرای فرآیند یا استفاده از ابزاری خاص (هر چند مدرن) کمکی به چابک‌تر شدن نمی‌کند. برعکس، از میان تیمی که حال خوب و تعاملات مناسب دارند، ابزار و فرآیندهای مناسب هم پدیدار می‌شوند.
لذا ابزارها و فرآیندها بایستی در خدمت بهبود و بهینگی تعاملات افراد باشند.

2. Working software over comprehensive documentation

در بیانیه‌ی توسعه‌ی چابک نرم‌افزار گفته شده روشی که چابک‌کاران در توسعه‌ی نرم‌افزار پیش می‌گیرند، روشی است که در آن به «نرم‌افزار در حال کار» نسبت به «مستندات مبسوط و جامع» ارزش و اهمیت بیشتری داده می‌شود.
به بیانی دیگر اگر سازمان یا تیمی در تحویل مرتب و منظم نرم‌افزار کاربردی، دچار مشکل باشد، تلاش برای تهیه مستندات جامع و مبسوط هم احتمالا کمکی به چابک‌تر شدن آنها نمی‌کند. مستنداتی ارزشمندند که بتوانند تحویل منظم و زود به زود نرم‌افزارِ در حال کار را تسهیل کنند.

3. Customer collaboration over contract negotiation

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

4. Responding to change over following a plan

در بیانیه‌ی توسعه‌ی چابک نرم‌افزار گفته شده روشی که چابک‌کاران در توسعه‌ی نرم‌افزار پیش می‌گیرند، روشی است که در آن «پاسخ‌گویی به تغییرات» از ارزش و اهمیت بیشتری به نسبت «پیروی از یک برنامه‌ی معین» برخوردار است.
به بیانی دیگر اگر سازمان یا تیمی، در پاسخ به تغییراتِ اثرگذار بر ویژگی‌های محصول، مشکلاتی داشته باشد و نتواند به موقع واکنش مناسب نشان دهد، اجرای مو به موی یک برنامه‌ی از پیش تعیین شده‌ هم احتمالا فایده‌ای نخواهد داشت.
لذا برنامه‌‌ها و برنامه‌ریزی‌ها باید به نحوی باشند وقوع تغییرات را حتمی دانسته و قابلیت پاسخ سریع نسبت به آنها را فراهم کنند.

معرفی کتاب Understanding Agile Values & Principles

سازمان‌هایی که تلاش می‌کنند تا واجد صفت «چابک» شوند، اگر از ارزش‌ها و اصول چابکی غفلت کنند یا دانش محدودی درباره نگرش (Mindset) چابک داشته باشند، اغلب به وضعیتی دچار می‌شوند که از چابکی تنها پوسته‌ای بر تن می‌کنند و چون به مغز و هسته‌ی چابکی توجه کافی ندارند، دور از انتظار نیست که همان روش‌های سنتی را با ظاهر چابک اجرا کنند.

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

اما ارزش‌ها و اصول چابکی چیستند؟ و چرا اهمیت آنها را دست‌کم می‌گیریم؟
نکته‌ این است که سادگی این ارزش‌ها باعث شده که آنها را بدیهی، دم‌دستی و سهل‌الوصول بدانیم. در حالی که اینگونه نیست و می‌توان گفت که:
که «چابک» آسان نمود اول، ولی افتاده مشکل‌ها.

اگر مایلید شرحی دقیق و صحیح از ارزشهای چابکی و اصول مربوطه بدانید، پیشنهاد می‌کنم این کتاب جمع و جور را که به تازگی توسط Scott Duncan نوشته شده و مورد تایید بزرگانی چون Ben Linders, Ken Robin, Mike Cohn و Ron Jeffries است را مطالعه کنید.

https://www.infoq.com/minibooks/agile-values-principles

دانلوددریافت فایل PDF

عنوان: Understanding-Agile-Values-Principals-Agile-Manifesto
حجم: 1.19 مگابایت
توضیحات: Understanding-Agile-Values-Principals-Agile-Manifesto

یافتن Bounded Context ها، چالشی همیشگی در Domain-Driven Design

تشخیص مناسب Bounded Context ها، کاری دشوار و پرچالش است. صاحب‌نظران این حوزه، بر پیچیدگی این کار مهر تایید زده‌اند و هر چند که با در میان گذاشتن تجربیات خود راهنمایی‌های ارزشمندی ارایه کرده‌اند اما جدال‌ها در این‌باره کم نشده و اتفاقا در سال‌های اخیر با مطرح شدن معماری Microservice، این بحث‌ها جدی‌‌تر هم شده‌اند. می‌شود گفت که هر جا که صحبت از Microservice است، رد پای Bounded Context هم دیده می‌شود و آن تفاوت نظرهایی که درباره مرزبندی سرویس‌ها وجود داشته، حالا دامن Bounded Context را هم گرفته است. با هم برخی نظرات را مرور کنیم:

Finding service boundaries is really damn hard... There is no flowchart!
- Udi Dahan

Microservices should cleanly align to bounded contexts.
- Sam Newman

Microservices is loosely-coupled, service oriented architecture with bounded context.
- Adrian Cockroft

One microservice should cover one bounded context
- Vaughen Vernon

Why is every one so eager to establish  a 1:1 mapping between microservices and bounded contexts?
- Alberto Brandolini

فارغ از این جدالها، در این نوشتار سعی می‌کنم تا به این پرسش پاسخ دهم که برای یافتن BC ها به چه نشانه‌هایی باید توجه کرد؟

از بوم مدل کسب و کار  شروع کنید!

بوم مدل کسب و کار (Business Model Canvas) یکی از شیوه‌های ساده و کاربردی در مدل‌سازی کسب و کار است. این بوم، می‌تواند نقطه شروع خوبی برای شناسایی BC ها و ارتباط آنها با یکدیگر (Context Map) قرار بگیرد. این بوم مشتمل بر ۹ بخش به شرح زیر است:

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

با دقت در بوم مدل کسب و کار به تصویری جامع از اجزای کلیدی مدل کسب و کار دست پیدا می‌کنید و این می‌تواند آغاز مسیری باشد که باید برای یافتن BC ها و مرزهای آنها طی کنید.

اطلاعات بیشتر: بوم مدل کسب و کار چیست؟

سرنخ‌ها را دنبال کنید!

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

۱- مرزهای معنایی واژگان را شفاف کنید.

اریک اوانس (Eric Evans) در کتاب Domain-Driven Design: Tackling Complexity in the Heart of Software از اهمیت زبان فراگیر (Ubiquitous Language) به تفصیل سخن می‌گوید. منظور از UL زبانی است که همه‌ی افراد درگیر در پروژه آن را درک کرده، از ابهامات معنایی خالی باشد و در همه گفتگوها، کدها، تست‌ها و مستندات از آن استفاده شود. اما این زبان فراگیر تشکیل نمی‌شود مگر اینکه context مشخص باشد. او context را اینگونه معنا می‌کند:

The setting in which a word or statement appears that determines its meaning.

بنابراین یکی از سرنخ‌هایی که به تشخیص BC ها کمک مهمی می‌کند، همین تغییر معنای کلمات است. مثلا کلمه «سفر» در کانتکست اعزام به ماموریت یک معنای کاملا متفاوتی در کانتکست گردشگری دارد.

۲- داده‌ها را در طول عمرشان بررسی کنید.

موضوعاتی مانند جریان داده، مالکیت داده‌، تضمین یکتایی داده‌ها و تاثیر ناشی از تغییرات داده بر داده‌های دیگر را مورد توجه جدی قرار دهید. به عنوان مثال اگر در تغییرات در داده‌های یک BC همواره باعث تغییر در  BC دیگری شود، می‌تواند نشانه‌ای از این باشد که مرزهای BC به درستی کشیده نشده‌اند.

۳- به متخصصین حوزه‌های مختلف (Domain Expert) پروژه توجه کنید.

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

۴- ساختار فعلی سازمان را زیر ذره‌بین ببرید.

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

If the architecture of the organization is at oods with the architecture of the system, the architecture of the organization wins.
--Ruth Malan

در جستجوی Autonomy

توجه کنید که وجه مشترک همه این سرنخ‌ها این است که آدرس Autonomy را به ما می‌دهند. Autonomy (استقلال داخلی) باعث ‌می‌شود تا تیم‌ها مستقل از هم کار کنند، وابستگی‌های دیتا و کدها کمینه شوند و در نهایت تحویل محصول سریعتر انجام شود. می‌شود گفت اگر BC ها طوری طراحی شوند که مانع تحویل زود به زود محصول شوند، یا تحویل یک BC وابسته به تحویل BC دیگری باشد، به احتمال زیاد در تشخیص BC ها دچار اشتباه شده‌ایم. اهمیت این موضوع تا این حد است که در بعضی منابع از Bounded Context به عنوان Autonomy Context نام برده شده است.

نکته پایانی: همه‌چیز در حال تغییر است.

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

---

منابع:

•     Domain-Driven Design: Tackling Complexity in the Heart of Software - Eric Evans
•     Nick Tune, DevoxxUK 2017
•     Finding Service Boundries - Udi Dahan
•     Thinking in Systems - Donella H. Meadows
  

هرم تست (Test Pyramid)

برای خودکارسازی تست نرم‌افزار می‌توان انواع متفاوتی از تست‌ را به کار گرفت. از تست‌های سطح پایین که برای تست قطعه کدهای نرم‌افزار نوشته می‌شوند، (Unit Test)؛ تا تست‌هایی سطح بالا که از واسط کاربری شروع می‌شوند و تست را به شکلی اجرا می‌کنند که گویا یک کاربر واقعی در حال کار با سیستم است. (End-To-End Test).

اما سوال کلیدی این است که وقت گذاشتن برای کدامیک از این انواع تست، نتیجه‌ی بهتری را عاید ما می‌کند؟ «هرم تست» پاسخی برای همین پرسش است.

همانطور که در شکل پیداست، بهتر این است که حجم تست‌های واحد (Unit Test) بسیار بیشتر از تست‌هایی باشد که از سطح UI اجرا می‌شوند.

تست‌های UI یا End-To-End Test

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

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

نکته دیگری که در مورد تستهای UI باید مورد توجه قرار داد این است که اجرای این تست‌ها معمولا تا رسیدن به یک Build موفق از سیستم به تاخیر می‌افتند و گاهی اوقات توسعه دهندگان برای اطمینان از عملکرد یک کد جدید باید منتظر بمانند تا دیگر اعضای تیم، کارشان را تا حد مناسبی پیش برده باشند. در این شرایط، رایج است که توسعه دهنده Back-End منتظر توسعه دهنده Front-End می‌ماند تا واسط کاربری پیاده‌سازی شود و پس از آن تست های UI اجرا شوند.

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

ببینیم در مورد تستهای واحد (Unit Test) وضعیت چطور است.

تستهای واحد (Unit Test)

نوشتن تست‌های واحد (Unit Test) ارزان است. فریم ورک‌های متنوعی برای نوشتن تست واحد وجود دارند که در عین برخورداری از قابلیت‌های فراوان، رایگان هم هستند.

تست‌های واحد، فیدبک سریعتری به توسعه دهنده می‌دهند. توسعه‌دهنده در کمتر از چندثانیه متوجه می‌شود که کد یا تغییرات جدید درست کار می‌کند یا نه.

نگهداری تست‌های واحد مشروط بر اینکه با رعایت بِه‌رَوشها نوشته شده باشند بسیار راحت‌تر است. اصلی‌ترین علت تغییر در اسکریپت‌های تست واحد زمانی است که کلاس یا کلاسهای مورد تست (Class Under Test) تغییر کنند. معمولا دامنه این تغییرات مربوط به چند کلاس محدود خواهد شد. این را مقایسه کنید با تست UI که حتی تغییر مکان یا نام یک Button می‌تواند کل سناریوی تست را بشکند.

مزیت دیگر تست واحد این است که در صورت شکست تست، تشخیص علت شکست به صورت دقیق و واضح امکان پذیر است. توسعه دهنده به راحتی می‌فهمد که کلاس یا متد خاصی (از بین هزاران کلاس یا متد) درست کار نمی‌کند و به همین دلیل، کمتر درگیر عملیات Debug خواهد شد.

 

جمع‌بندی:

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

 

این بحث را در وبینار خودکارسازی تست نرم‌افزار دنبال خواهیم کرد و بیشتر با Unit Test آشنا خواهیم شد. برای کسب اطلاعات بیشتر مراجعه کنید به:

https://evand.com/events/softwaretesting-2nd

تست خودکار نرم‌افزار؛ از آغاز تا انجام

🔸اپیزود اول:

وقتی مشتری درخواست جدیدی می‌دهد، دست و دل ما می‌لرزد که نکند انجام این تغییرات، به جاهای دیگر سیستم هم گند بزند! چون سیستم بزرگ و پیچیده‌ای داریم، می‌ترسیم اینجا را تغییر دهیم و جای دیگری خراب شود و نفهمیم که خراب شده! یا وقتی بفهمیم که خیلی دیر شده! تا می‌آییم یک باگ را رفع کنیم، ۱۰ باگ دیگر ایجاد می‌شود! روحیه و انرژی تیم پایین آمده و جرات تغییر و دست زدن به کدهای قدیمی را نداریم!

🔸اپیزود دوم:

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

🔸اپیزود سوم:

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

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

💡مجموعه وبینارهای «تست خودکار نرم افزار، از آغاز تا انجام» با این هدف ارایه می‌شوند تا موضوع تست خودکار نه تنها به عنوان یک مهارت بلکه به عنوان یک هنر، در تیم‌ها جدی گرفته شود. تست نوشتن با تستِ خوب نوشتن، متفاوت است. در قسمت اول به موضوع Unit Test پرداخته می‌شود.

📌تاریخ برگزاری: جمعه، 21 اردیبهشت، ساعت 15

کسب اطلاعات بیشتر و ثبت نام:

🌐https://evand.com/events/softwaretesting

درباره Event Storming

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

آیا می‌شود گفتگوی تیم توسعه و متخصصین دامین را در قالب یک کارگاه باحال و انرژی بخش برگزار کرد؟ بله!
چگونه؟ Alberto Brandolini در این مطلب درباره ایده Event Storming صحبت میکند. ایده ای که اخیرا هم در سومین کنفرانس DDD Europe در قالب کارگاه به شرکت کنندگان آموزش داد و البته مورد توجه و استقبال خوبی قرار گرفت.

Introducing Event Storming

تاملی در روش تفکیک Bounded Context ها

در رویکرد طراحی دامنه‌گرا (Domain Driven Design)، برای کنترل و غلبه بر پیچیدگی‌های فضای مسٔله، مرزهایی بین اجزای متنوع دامنه تعریف می‌شود که به Bounded Context مشهور است. تشخیص این مرزها و تصمیم گیری درمورد اینکه هر جزء فضای راه حل، در حوزه کدام BC قرار دارد، از جمله تصمیمات مهم و راهبردی طراحی محسوب می‌شود. برای درک بهتر کارکرد Bounded Context ها به شکل زیر توجه کنید:

هرچند نباید انتظار داشت که تشخیص Bounded Context ها در همان ابتدا بدون اشکال باشد، اما با بکارگیری تکنیک‌هایی می‌توان از خطاهای مهلک طراحی اولیه کم کرد، تا طراحی منطقی و منعطف‌تری داشته باشیم.

در این مطلب، نویسنده به شرح تکنیکی برای تشخیص و مدل کردن بهتر Bounded Context ها می‌پردازد. تکنیکی به نام: "Intentional Naivety First"

▫️حتی اگر با رویکرد Domain Driven Design آشنا نیستید، باز هم این مطلب واجد نکات آموختنی بسیاری است.

https://medium.com/nick-tune-tech-strategy-blog/intentional-naivety-first-bounded-context-modelling-62e6211574ec

پشتیبانی EF Core از الگوهای DDD

برنامه نویسان دات نت برای بکارگیری پترن‌های DDD همواره با چالش ORM ها مواجه بوده‌اند. Entity Framework 6 به سختی از الگوهای DDD پشتیبانی می‌کرد و NHibernate هم با توجه به کاهش فعالیت توسعه دهندگانش، دیگر انتخاب چندان  موجهی نیست. اما گویا این چالش با EF Core 2 به فراموشی سپرده می‌شود.

در این مطلب Julie Lerman توضیح می‌دهد که ORM کاملا بازطراحی شده‌ی EF Core 2  انتخاب مناسبی برای ORM دومین‌هایی است که الگوهای #DDD را به‌کار گرفته‌اند.

https://technet.microsoft.com/en-us/mt842503.aspx

پی نوشت: Julie Lerman  اخیرا در کنفرانس DDD Europe 2018 ارایه‌ای داشت با عنوان:
Exploring EF Core Support for DDD Patterns

https://dddeurope.com/2018/speakers/julie-lerman/  #DDDEU

کنفرانس DDD Europe

کنفرانس DDD Europe مهمترین رویداد سالانه برای علاقه‌مندان به موضوعاتی مانند Domain Driven Design, Event Sourcing, Event Storming, Microservice, CQRS است. کنفرانسی که به اعتبار سخنرانان و برگزارکنندگانش از سوی بعضی‌ها به عنوان «سوپر کنفرانس» لقب گرفته است.

امسال سومین سالیست که این رویداد جریان ساز و مهم برگزار می‌شود. شهر آمستردام از سی‌ام ژانویه تا دوم فوریه ۲۰۱۸، میزبان حدود ۷۰۰ نفر از شرکت کنندگانِ این کنفرانس مهم و جریان ساز است. کارگاه‌های این کنفرانس از ۲ روز پیش شروع شده‌اند و از امروز برنامه‌ی سخنرانی‌ها، با سخنرانی درخشان و تامل برانگیز پرفسور Dave Snowden با عنوان (Complex Adaptive Systems) شروع شد. از دیگر سخنرانان کلیدی این کنفرانس می توان به Eric Evans اشاره کرد.

برای پیگیری رویدادهای مرتبط با این کنفرانس می توانید هشتگ #DDDEU و یا #DDD_EU را در توییتر دنبال کنید.

توییتر کنفرانس

معرفی دو کتاب در حوزه مایکروسرویس و توسعه اپلیکیشنهای مبتنی بر Container برای توسعه دهندگان .Net

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

1- Containerized Docker Application Life-cycle with Microsoft Platform and Tools 

Download Link: http://ligman.me/2v7M0bp

2.  .NET Microservices Architecture for Containerized NET Applications

Download: http://ligman.me/2sLiBTE