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

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

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

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

دانلود مقاله

داستان 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/

نقد و نظر

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

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

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