تشخیص مناسب 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