پترن‌ها، رهیافت‌ها (Heuristics) و فیل‌ها!


به دست سردبیر

پترن‌ها، رهیافت‌ها (Heuristics) و فیل‌ها! چرا فیل‌ها؟ چون فیل‌ها به مانند پدیده قابل مشاهده یا یک پترن در طبیعت می‌باشند. آن‌ها را می‌بینیم، به روش‌ها مختلف توصیف می‌شوند و اطلاعاتی درباره‌شان ارائه می‌شود و حتی بعضی‌ها ادعا می‌کنند که همه چیز را درباره فیل‌ها می‌دانند. اما در حقیقت دانش ما از فیل‌ها محدود می‌باشد.

این مقاله با در نظر گرفتن فیل‌ها به عنوان یک مثال خوب در این زمینه به چالش‌ها، تابوها و مشکلات مربوط به درک و استفاده از پترن‌ها و رهیافت‌ها می‌پردازد. اما این موارد چه چیزهایی می‌توانند باشند؟ چالش نحوه ارائه و توضیح یک پترن برای نویسندگان این حوزه، نحوه برخورد با پترن‌های جدید و نوظهور، ایده داشتن یک کتاب فقط برای یک پترن خاص، نحوه ادراک پترن‌ها، حداقل پرسشگری مورد نیاز و … تنها نمونه‌هایی از موضوعاتی هستند که می‌توان در مورد آنها صحبت کرد. این مشکلات و دغدغه‌ها به مانند فیل در اتاق (The elephant in the room) وجود دارند اما کسی درباره آن‌ها حرفی نمی‌زند.

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

دانلود مقاله

TDD for Beginners

اطلاعیه برگزاری وبینار TDD


به دست سردبیر

رویکرد Test-Driven Development شیوه‌ای از توسعه نرم‌افزار است که به توسعه‌دهندگان پیشنهاد می‌کند که قبل از شروع کد نویسی برای فیچر جدید، انتظار خودشان از عملکرد آن فیچر را به صورت تست‌های خودکار بنویسند و سپس شروع کنند به نوشتن کد تا جایی که نتیجه تست‌ها موفق شود.

در این وبینار، همین ایده کلیدی TDD در عمل نمایش داده می‌شود تا مخاطب درک کند که این ایده چطور می‌تواند اجرا شود و نتیجه‌ی اجرای آن چه تاثیری بر سادگی طراحی‌های ما خواهد گذاشت.

برای همین منظور، می‌رویم سراغ اعداد رومی و سعی می‌کنیم برنامه‌ای بنویسیم که اعداد انگلیسی را به معادل رومی آن تبدیل کرده و نمایش دهد.

ارائه‌دهندگان این وبینار، مساله نمایش اعداد رومی را در قالب اجرای کد کاتا (Code Kata) پیش خواهند برد و با حفظ اصول TDD مساله را حل خواهند کرد.
علاوه بر این، در این ارائه شما می‌توانید نظاره‌گر این باشید که دو نفر چطور می‌توانند Pair Programming انجام دهند.

تاریخ: ۱۶ اردیبهشت ۱۴۰۰ | ساعت ۱۶ الی ۱۸
این وبینار رایگان است.
لینک ثبت‌نام: https://evand.com/events/tdd-for-beginners

اهمیت طراحی ماژولار در رویکرد DDD


به دست سردبیر

به نظر می‌رسد که مفهوم Module به نسبت دیگر مفاهیم مطرح در رویکرد Domain-Driven Design کمتر مورد توجه طراحان و توسعه‌دهندگان قرار می‌گیرد.

مشاهدات شما چیست؟ آیا اهمیت مفهوم Module و طراحی Modular آن‌طور که باید و شاید در تیم‌‌هایی که با آنها کار کرده‌اید درک و رعایت شده است؟
به نظر شما چرا مفهوم Module زیر سایه مفاهیم دیگری مثل Aggregate, Value Object, Domain Service و … کمرنگ‌تر شده است؟ و کمرنگ شدن این مفهوم چه آسیبی به غنای مدل وارد می‌کند؟

برای بحث و گفتگو در این باره می‌توانید به گروه انجمن DDD ایران وارد شوید. به این نشانی:

https://t.me/ddd_iran_discussion

وبینار بکارگیری اصول Functional Programming در توسعه با رویکرد Domain-Driven Design


به دست سردبیر

چگونه دو پارادایم Functional Programming و Domain-Driven Design می‌توانند دست در دست هم به ایجاد یک مدل منعطف و غنی کمک کنند؟

چگونه می‌توانیم از مفاهیم بنیادی مطرح در Functional Programming مانند داده‌های جبری، ترکیب‌پذیری (Composition) و توابع خالص (Pure Functions) برای پیاده‌سازی قواعد دامین استفاده کنیم؟

چگونه می‌توانیم ضمن رعایت اصل تغییرناپذیری داده‌ها (Immutability) که به عنوان یک اصل بنیادی در دنیای FP مطرح است، از تکنیک‌های طراحی مطرح در DDD استفاده کنیم؟

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

زمان: پنج‌شنبه ۲۳ بهمن ۱۳۹۹ – ساعت ۱۸ به وقت تهران
شرکت در این وبینار رایگان است.
ثبت‌نام:
https://evand.com/events/functional-programming-in-ddd

شروع فعالیت گروه پرسش و پاسخ انجمن DDD ایران


به دست سردبیر

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

با عضویت در این گروه می‌توانید با دیگران علاقه‌مندان به مباحث طراحی و مدل‌سازی دامین ارتباط بگیرید و تجارب خود را با هم به اشتراک بگذارید.

لینک ورود:
https://t.me/ddd_iran_discussion

  • انجمن DDD ایران

اطلاعیه برگزاری کارگاه آموزشی: «چگونه با ریفکتور ساندویچی کد خود را لذیذتر کنیم؟»


به دست سردبیر

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

مدرسان: سپهر نامدار و هادی احمدی

تاریخ: جمعه دهم بهمن – ساعت ۱۶:۳۰ الی ۱۸:۳۰

🔺ظرفیت شرکت در این کارگاه محدود و تنها ۲۴ نفر است.

جهت کسب اطلاعات بیشتر و ثبت‌نام، مراجعه کنید به:

https://evand.com/events/refactoring-with-the-sandwich-pattern-413138

کارگاه آموزشی با عنوان: Testing Invariants with Property-Based Testing


به دست سردبیر

اولین قدم در توسعه Domain Model بعد از شناخت مساله، تقسیم مساله به بخش‌های کوچک و توسعه این بخش‌های کوچک به شکل Iterative و Incremental می‌باشد. TDD تکنیکی است که بسیاری از برنامه‌نویسان برای این منظور استفاده می‌کنند. اما عمده برنامه‌نویسان برای نوشتن تست‌های خود از رویکرد Example-Based (مثال-محور) استفاده می کنند و روش‌های دیگر را در نظر نمی‌گیرند.

می‌توان گفت Property-Based Testing ما را ملزم می‌سازد تا در مورد تست‌هایی که می‌نویسیم، متفاوت‌تر فکر کنیم.
در شیوه Property-Based Testing تست‌ها نه با نوشتن مثال، بلکه با توصیف قوانین و خصوصیات نوشته می‌شوند و سپس مثال‌ها توسط فریم‌ورک‌های مربوطه تولید می‌شوند.

در این کارگاه آموزشی، ما تست‌های یک Domain Model را به صورت Property-Based و با رویکرد TDD می‌نویسیم و بررسی می‌کنیم که با استفاده از Property-Based Testing چگونه می‌توان Invariant ها را در تست به بخش‌های کوچک‌تر تقسیم کرد و در گام‌های کوچک توسعه داد.

هدف از این کارگاه این است که به شرکت کنندگان نشان دهد که چگونه می‌توانند از Property-Based Testing به عنوان ابزاری برای کاوش و بررسی عمیق‌تر مساله و توسعه با گام‌های کوچک استفاده کنند.

مدرسان: هادی احمدی و سپهر نامدار

تاریخ: جمعه سوم بهمن – ساعت ۱۶:۳۰ الی ۱۸:۳۰

🔺ظرفیت شرکت در این کارگاه محدود و تنها ۲۴ نفر است.

جهت کسب اطلاعات بیشتر و ثبت‌نام به لینک زیر مراجعه کنید:
https://evand.com/events/testing-invariants-with-property-based-testing-8902

داستان Uber و مایکروسرویس


به دست سردبیر

مطالعه داستان‌های بکارگیری متدهای نوین در شرکت‌های بزرگ فناوری می‌تواند ارزشمند و آموزنده باشد. این یکی از داستان‌های خواندنیست که مهندسان شرکت Uber توضیح می‌دهند که چرا و چگونه به سوی معماری مایکروسرویس مهاجرت کرده‌اند. مهندسان اوبر در این مطلب، سبکی از معماری مایکروسرویس را پیش گرفته‌اند که خودشان آن را Domain-Oriented Microservice Architecture نامیده‌اند.

بخشی از این مطلب:

As a result, we adopted a microservice architecture. Ultimately our systems became more flexible, which allowed teams to be more autonomous.

🔘 System reliability. Overall system reliability goes up in a microservice architecture. A single service can go down (and be rolled back) without taking down the whole system.

🔘 Separation of concerns. Architecturally, microservice architectures force you to ask the question “why does this service exist?” more clearly defining the roles of different components.

🔘 Clear Ownership. It becomes much clearer who owned what code. Services are typically owned at the individual, team, or org level enabling faster growth.

🔘 Autonomous execution. Independent deployments + clearer lines of ownership unlock autonomous execution by various product and platform teams.

🔘 Developer Velocity. Teams can deploy their code independently, which enables them to execute at their own pace.

منبع: https://eng.uber.com/microservice-architecture/

بررسی چالش‌های تیم‌ها/سازمان‌ها در بکارگیری رویکرد Domain-Driven Design


به دست سردبیر

در این وبینار که به میزبانی انجمن DDD ایران برگزار شد، جمعی از علاقه‌مندان به رویکرد Domain-Driven Design گرد هم آمدند و درباره موانع و چالشهای عملی که در بکارگیری این رویکرد با آن مواجه شده بودند، به بحث و گفتگو پرداختند.
دوم آبان ۱۳۹۹

نقد و نظر


به دست سردبیر

کریس ریچاردسون (Chris Richardson) یکی از افراد صاحب‌نظر در حوزه معماری مایکروسرویس است. او در اکثر سخنرانی‌های خود بر این نکته تاکید می‌کند که «تا جای ممکن از معماری Monolith استفاده کنید.» و فقط و تنها فقط زمانی از معماری مایکروسرویس استفاده کنید که مطمنید معماری مانولیت دیگر برای شما کافی نیست.
در اغلب موارد می‌توانید اقدامات زیر را انجام دهید و همچنان از مزایای معماری مانولیت بهره‌مند شوید:

Make the most of the monolithic architecture.
The monolithic architecture is not an anti-pattern.
If software delivery is slow =>
▫️Optimize development process
▫️Improve deployment pipeline = more automation
▫️Improve team autonomy
▫️Modularize the monolith
▫️Eliminate hand-offs and create cross functional teams
▫️If technology stack is obsolete => modernize to a new monolith
…

بیشتر بخوانید: https://www.slideshare.net/chris.e.richardson/decompose-your-monolith-strategies-for-migrating-to-microservices-tide