کارگاه آموزشی با عنوان: 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

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

دوم آبان ۹۹، وبیناری به میزبانی انجمن DDD ایران برگزار شد که موضوع آن «بررسی چالش‌های تیم‌ها و سازمان‌ها در بکارگیری رویکرد Domain-Driven Design» بود.

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

اینک می‌توانید ویدیوی این وبینار را از طریق لینک زیر مشاهده کنید:
🎞 https://aparat.com/v/d3O8E

اطلاعیه برگزاری جلسه بحث آزاد

📣اطلاعیه برگزاری جلسه بحث آزاد

اطلاعیه برگزاری جلسه بحث آزاد انجمن DDD ایران

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

این جلسه آنلاین و شرکت در آن رایگان است.

⏱ زمان: جمعه دوم آبان ۱۳۹۹ – ساعت ۱۸ الی ۲۰

💭 لینک ورود: https://m.teamlink.co/8587898606

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

https://www.teamlink.co/download.html

مایکروسرویس یا مانولیت؟

کریس ریچاردسون (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

ویدیوی وبینار Domain Story Telling ارایه شده توسط استفان هافر

ویدیوی وبینار Domain StoryTelling که با حضور استفان هافر و با میزبانی انجمن DDD ایران برگزار شد:

https://youtu.be/TaC1dr8bKAM
اسلایدهای ارائه:
https://speakerdeck.com/hofstef/an-introduction-to-domain-storytelling-at-ddd-iran-eng
استفان هافر در این ارایه، دریچه‌ای گشود به دنیای قصه‌گویی و درک فضای مساله از میان روایت‌های متخصصان دامین.
تصویرسازی قصه‌ها همیشه جذاب است و استفان در این وبینار نشان داد که چگونه می‌توان با زبان تصاویر به روایت این داستان‌ها پرداخت.

دعوت برای ارایه وبینار آموزشی

انجمن DDD ایران بدینوسیله از علاقمندان به ارایه وبینار آموزشی در حوزه‌های زیر دعوت می‌کند تا برای هماهنگی و کسب اطلاعات بیشتر با آیدی تلگرام @Iran_DDD_Community و یا با ایمیل info@dddiran.com مکاتبه کنند.

🔘موضوعات مرتبط با رویکرد Domain-Driven Design
🔘 الگوهای مدرن در معماری‌ سامانه‌های توزیع شده
🔘 معماری‌های مدرن و تاثیر آنها بر چابکی توسعه محصول
🔘 ابری‌سازی سرویس‌ها، زیرساخت‌ها و فرهنگ Dev-Ops
🔘 موضوعات مرتبط با خودکارسازی تست نرم‌افزار
🔘 موضوعات مرتبط با بدهی‌فنی، ریفکتورینگ و مهاجرت از سامانه‌های مونولیت

☑️ نکات مهم:
۱- تاریخ ارایه وبینار، از پیش تعیین شده نیست و طی هماهنگی با ارایه دهنده‌ی وبینار تعیین خواهد شد.
۲- این فراخوان تاریخ پایان ندارد و هر زمان که برای ارایه وبینار آمادگی داشتید می‌توانید موضوع را با انجمن در میان بگذارید.

حیات در حصار یک سلول

مفهوم مرزبندی در بیشتر پدیده‌های پیرامون ما دیده می‌شود. گاهی این مرز بندی ناخوشایند است مثل مرز بین ملت‌ها و فرهنگ‌ها؛ گاهی این مرزها هستند که حتی حیات همه موجودات زنده و میلیاردها سلول زنده بدن آنها را سبب می‌شوند.
می دانیم اساسی‌ترین چالش در طراحی، تعیین مرز دقیق Bounded Context ها است. اما به راستی ضرورت این مرزبندی چیست؟
در این ارائه، ابراهیم نبیئی به چیستی Bounded Context ها به عنوان الگوی محوری DDD می‌پردازد و چرایی مرزبندی بین BC ها را از منظر دیگری بررسی می‌کند.