تاملات گاه گاه یک توسعه دهنده نرم افزار

درباره 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


Containerized Docker Application Lifecycle with Microsoft Platform and Tools


2.  .NET Microservices Architecture for Containerized NET Applications

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



۰ نظر موافقین ۰ مخالفین ۰
روح الله دلپاک

اصل Persistence Ignorance

اصل Persistence Ignorance به طور خلاصه بیان می‌کند که در تحلیل و طراحی Business Logic به موضوع ذخیره‌سازی (Persistence) فکر نکنید (تا جای ممکن) یا به عبارت دیگر، ذهن خود را درگیر پیچیدگی‌های ذخیره سازی نکنید. چرا باید موقع طراحی دامین‌مدل، به موضوعاتی مثل تریگر، روالهای ذخیره شده،‌ نرمال‌سازی دیتا، کلید اصلی، کلید فرعی و ... فکر کرد؟

اصل PI در واقع منشا شده از اصل Separation of Concerns است. مساله دامین از مساله ذخیره سازی سواست. ابتدا مسله دامین را حل کنید؛ چون اصلی‌ترین مسله همینجاست. به مسله ذخیره‌سازی هم در جای خود بپردازید.

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

الگوی Repository Pattern هم در واقع امکانی برای تحقق این اصل است. این الگو به شما کمک می‌کند که دامین شما درگیر مکانیسم ذخیره‌سازی نشود.

۱ نظر موافقین ۰ مخالفین ۰
روح الله دلپاک

اصل Dependency Inversion و ارتباط آن با معماری نرم‌افزار

اصل Dependency Inversion

تشریح اصل DI فراتر از حوصله‌ی این نوشته است و در اینجا در حد موضوع این نوشتار به آن می‌پردازیم. اصل Dependency Inversion را مرور کنیم. می‌گوید:


High-level modules should not depend on low-level modules. Both should depend on abstractions


این اصل یعنی چه؟ مفهوم «رانندگی اتومبیل» را به عنوان یک مفهوم انتزاعی سطح بالا در نظر بگیریم. شما به عنوان یک راننده پشت فرمان هر خودرویی که بنشینید بهتر است که درگیر پیچیدگی‌های غیر ضروری مانند تعداد سیلندر و مشخصات فنی و ... نشوید و برای شما نباید فرق کند که مثلا سوخت ماشین بنزین است یا ماشین الکتریکی سوار شده‌اید. مفهوم «رانندگی» نباید وابسته به مفاهیمی مانند موتور و کاربراتور و ... باشد. شما میخواهید ماشین را برانید و چیزی که برای شما اهمیت دارد چیزهایی مانند فرمان، تعداد دنده‌ و مکان کلاج و پدال است. این مفاهیم مفاهیمی «هم سطح» با مفهوم «رانندگی» هستند. به این ترتیب می‌توانید تجربه رانندگی را مستقلا حفظ کنید و این مفهوم سطح بالا (رانندگی) از یک ماشین به ماشین دیگر (low-level modules) دستخوش تغییر نشود. (فرض کنید که رانندگی هر ماشینی با ماشین دیگر کاملا متفاوت بود و برای یادگیری رانندگی هر ماشین باید آموزش جداگانه‌ای می‌دیدید.) چیزی که اهمیت بیشتری دارد مفهوم سطح بالای رانندگی است و چیزهایی که تغییر می‌کند، مفاهیم سطح پایین تری مانند مدل ماشین و موتور و ... هستند.

برای اینکه اصل DI را به معماری هم تعمیم دهیم طراحی و وابستگی لایه‌ها را به نحوی تعریف می‌کنیم که مفاهیم سطح بالا (High-level modules) وابستگی به مفاهیم سطح پایین‌تری مانند زیرساخت، سرویس‌های بیرونی، واسط کاربر، ذخیره‌سازها و ... نداشته باشد. چرا؟ مانند مثالی که زدم، اگر این سطوح انتزاع را رعایت نکنیم، مفهوم «رانندگی» با مفاهیم جزیی‌تر وابستگی پیدا می‌کند و «پیچیدگی» غیر قابل کنترل می‌شود.


اصل DI و قدرت آن در کنترل پیچیدگی


در مواجهه با پیچیدگی‌ها، برای اینکه بتوان پیچیدگی را به کنترل در بیاوریم ، عموما ۳ اقدام را به صورت هماهنگ انجام می‌دهیم.


1- Decomposition

2- Hierarchy

3- Abstraction


اگر به تعریف اصل DI که در ابتدای این نوشته به آن اشاره شد توجه کنید،‌ میبینیم که این اصل به طور غیر مستقیم هم به Hierarchy (High/low level) اشاره کرده، هم به Abstraction و هم به  Decomposition (Not Depend…). لذا معماریهایی که اصل DI در طراحی آنها به درستی مورد توجه قرار گرفته باشد به همین دلیل در غلبه بر پیچیدگی موفق‌تر هستند که به طور ضمنی، طراحان و توسعه دهندگان را به اقدامات سه گانه‌ی Decomposition, Hierarchy, Abstraction سوق می‌دهند.


اصل DI و ارتباط آن با معماری نرم افزار

ابتدا توجه شما را به این نقل قول جلب می‌کنم:


If you apply the Dependency Inversion Principle to Layered Architecture, you end up with Ports and Adapters.
-Mark Seemann


مشکلی در معماری موسوم به Layered Architecture وجود داشت این بود که Domain Logic به لایه Data Source وابسته بود. یعنی تجربه رانندگی، مثلا به تعداد سیلندرهای ماشین وابسته شده بود!

معماری های موسوم به Onion و Hexagonal یا همان (Ports & Adapters) جهت این وابستگی را اصلاح کردند. یعنی هر چه مربوط به Domain نبود را در بیرون از دایره (یا شش ضلعی یا ...) قرار دادند. دامین در مرکز قرار گرفت و لایه‌های دیگر (لایه های Mechanism و Utility) مجاز بودند که به دامین دسترسی داشته باشند (با واسطه) ولی خود دامین نمی‌تواند هیچ وابستگی به لایه‌های خارجی (بیرون از دایره وسطی) داشته باشد.



از جمله نتایج این طراحی این است که:

۱- قواعد کسب و کار و ... به طور کامل از جزییات دیگر منفک شود. بهبود از منظر Cohesion & Coupling

۲- مدل (Domain Model) خوانا و قابل فهم شود و توسعه آن آسانتر شود.

۳- طراحی Test Friendly شود.

۴- دامین مدل از دیتا سورسها مستقل شود. به این ترتیب امکان ایجاد تنوع در دیتا سورسها فراهم می‌شود. (یادمان بیاید که تغییر ظرفیت باک ماشین تجربه رانندگی را مختل نمی‌کند)


هر چند هر دو معماری Onion و Hexagonal در این وجوه با هم مشترکند اما جناب پالرمو (مطرح کننده معماری Onion) خلاقیت به خرج دادند و دو مفهوم، به آن اضافه کردند.

1- Domain Service

2- Application Service

به دلیل اینکه این مفاهیم نزدیک و هماهنگ با پترنهای مطرح در DDD هستند این سبک معماری را DDD Friendly به نظر می‌رسد. (مفهوم Application Service همان مفهوم Adapters است.)

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

I must stress again:  I am not claiming any breakthroughs in technology or technique.  I have learned from other industry thought leaders like Martin Fowler, Ward Cunningham, Kent Beck, Michael Feathers and others

برای مطالعه بیشتر درباره شباهت‌های مفهومی معماری‌های Hexagonal و Onion مطالعه لینک زیر پیشنهاد می‌شود.

http://blog.ploeh.dk/2013/12/03/layers-onions-ports-adapters-its-all-the-same/

۱ نظر موافقین ۰ مخالفین ۰
روح الله دلپاک

تاملی در مفهوم «طراحی پدیدآ» (Emergent Design)

در توسعه محصولات نرم‌افزاری، سه تصور یا پیش فرض غلط وجود داشته و بعضا هنوز هم وجود دارد:

۱- مشتریان از نیازمندی‌های خود آگاهند.
۲- توسعه دهندگان روش ساخت محصول را می‌دانند.
۳- در مدت توسعه چیزی تغییر نمی‌کند.

تجربه نشان داده که اینطور نیست و چنین فرضیاتی در اغلب موارد و به خصوص در تولید محصولات پیچیده و یا نوآورانه غلط هستند و در واقع:

۱- مشتری/ذینفع به مرور به جزییات نیازمندیهای خود پی می‌برد.

۲- توسعه دهنده ها بر اساس یافته های جدیدشان میفهمند که محصول را چگونه بهتر از قبل بسازند.

۳- در حین توسعه، به چیزهای جدیدی یاد می‌گیریم و این یادگیری‌ها میتواند برنامه‌های قبلی را به طور کامل عوض کند.


متدهای چابک هم بر مبنای همین تجربیات پایه گذاشته شدند. رویکردی که از پیش بینی (Prediction) فاصله گرفت و پذیرای تغییر و تطبیق با شرایط جدید (Adaption) شد.

بر اساس همین رویکرد جدید (چابکی) می‌پذیریم، طراحی های ما به مرورد «بهتر» و «پدیدار»‌ می‌شوند و به تدریج به شکل مطلوب در می‌آیند. به تجربه ثابت شده که ایده‌ی طراحی «کامل» (GOD Design) ایده‌ای است که در عمل شکست می‌خورد. لذا می‌پذیریم که پیش بینی‌های بلند مدت نکنیم و به جای آن پذیرای تغییرات باشیم. البته این تغییرات مبتنی بر یادگیری معتبر (Validated Learning) هستند. شاید این حرف بدیهی به نظر برسد اما ایده یک طراحی جامع و زودهنگام (Big Up Front Design) که بشود بر اساس آن برنامه دقیقی ارایه داد، مدتها مطرح و در متدلوژی‌های سنگین وزن (Plan-Driven) معتبر بوده است.

طراحی پدیدآ و ارتباط آن با بیانیه چابک

در بیانیه چابک، اصل یازدهم گفته شده که:

The best architectures, requirements, and designs emerge from self-organizing teams.

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

Welcome changing requirements, even late in development.

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

برای مطالعه بیشتر میتوانید این مطلب را بخوانید:

http://www.scaledagileframework.com/agile-architecture/

همینطور خواندن کتاب  Lean Architecture for Agile Software Development نوشته جیمز کاپلین، مخصوصا فصل ۵ را پیشنهاد می‌کنم.

۱ نظر موافقین ۰ مخالفین ۰
روح الله دلپاک

از بازیهای کودکان می شود آموخت

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

مهرانا بازی مار و پله را به خوبی بلد بود. چیزی که برای من جالب بود، تفاوت دیدگاه من و مهرانا بود. تاکید داشت که این یک بازی دیگریست، با قواعد دیگر؛ اما من تاکید داشتم که این همان مار و پله است و قواعدش هم باید همان باشد.

اینجا بود که به یاد مفهوم Shu-Ha-Ri افتادم. خواستگاه این مفهوم هنرهای رزمی ژاپنیست. بیان این مفهوم به این شکل است که برای استاد شدن باید سه مرحله را پشت سر گذاشت. مرحله اول یادگیری اصول، مبانی و تکنیک‌ها از  استاد به صورت دقیق و مو به مو است (Shu). مرحله بعد رها شدن از آموزش‌های رسمی است. در این مرحله یادگیرنده به بررسی عمیق‌تر تئوری‌ها می‌پردازد و از سایر اساتید، فنونی یاد می‌گیرد و ادغام می‌کند.(Ha). در مرحله ی آخر (Ri)، فرد صاحبِ سبک منحصر به خودش شده است و بر اساس تجربیات و آموخته‌های خودش تصمیم می‌گیرد و اقدام می‌کند.

مهرانا در بازی مار و پله، به همان مرحله سوم رسیده بود. قوانین خودش را داشت و بازی را جوری عوض کرده بود که احتمال برنده شدنش بیشتر شود. اما چرا خیلی از ما هنوز در قوانین ابتدایی بازی مار و پله مانده‌ایم؟!

۰ نظر موافقین ۰ مخالفین ۰
روح الله دلپاک

نگاهی به پدیده «طفره‌روی اجتماعی» و تاثیر آن بر فعالیت تیم‌های چابک

مقدمه:

فعالیت تیمی مستعد آسیب‌هایی است. مسلما مطالعه و شناخت آسیب‌ها، می تواند باعث جلوگیری از آسیب یا مواجهه اصولی و سنجیده‌تر با آن شود. یکی از آسیب‌هایی که فعالیت تیمی را مورد تهدید قرار می‌دهد، پدیده‌ای است به نام «طفره‌روی اجتماعی» (Social Loafing). هدف از این یادداشت بررسی اجمالی این پدیده و تاثیر آن بر فعالیت تیم توسعه نرم‌افزار است.

۱ نظر موافقین ۰ مخالفین ۰
روح الله دلپاک