آیا معماری و طراحی یکی نیستن؟
نه، معماری و طراحی یکی نیستن.
معماری بیشتر به ساختار مربوطه، نه ظاهر؛ در حالی که طراحی بیشتر به ظاهر مربوطه، نه ساختار. مثلاً رنگ دیوارها، چیدمان مبلمان، یا نوع کفپوش (فرش یا چوب) جزو طراحی محسوب میشن؛ ولی اندازهی اتاق و محل قرارگیری درها و پنجرهها مربوط به معماریه—یعنی ساختار اتاق.
در یک اپلیکیشن تجاری معمولی، معماری یعنی اینکه صفحات وب چطور با سرویسهای پشتیبان و پایگاه داده ارتباط برقرار میکنن تا دادهها رو ذخیره یا بازیابی کنن. اما طراحی یعنی ظاهر هر صفحه: رنگها، جای فیلدها، الگوهای طراحی و موارد مشابه. باز هم میرسیم به تفاوت ساختار در برابر ظاهر.
خیلی وقتها تشخیص اینکه چی معماریه و چی طراحی، گیجکننده است. بیاییم این تفاوتها رو دقیقتر بررسی کنیم.
نگاه طراحی
فرض کن شرکتت میخواد سیستم قدیمی ثبت سفارش رو با یه سیستم جدید و اختصاصی جایگزین کنه که دقیقاً با نیازهاش هماهنگ باشه. در این سیستم، مشتریها میتونن سفارش ثبت کنن، اونها رو ببینن یا لغو کنن، و هزینه رو با کارت اعتباری، کارت هدیه، یا ترکیبی از هر دو پرداخت کنن.
از زاویهی طراحی، ممکنه یه نمودار کلاس UML بسازی تا نشون بدی کلاسها چطور با هم تعامل دارن تا بخش پرداخت رو پیادهسازی کنن. هرچند میتونی بر اساس این طراحی کد بنویسی، اما این نمودار چیزی دربارهی ساختار فیزیکی کدها نمیگه—یعنی اینکه فایلهای کلاس چطور سازماندهی و مستقر میشن.
نگاه معماری
برخلاف طراحی، معماری به ساختار کلی سیستم مربوطه—مثل سرویسها، پایگاههای داده، و نحوهی ارتباط سرویسها با هم و با رابط کاربری.
اگه دوباره به همون سیستم سفارش فکر کنیم، از دید معماری ممکنه تصمیم بگیری برای هر نوع پرداخت یه سرویس جداگانه بسازی، و یه سرویس هماهنگکننده (orchestrator) داشته باشی که کل فرآیند پرداخت رو مدیریت کنه.
طیف بین معماری و طراحی
بعضی تصمیمها قطعاً معماری هستن—مثل انتخاب سبک معماری مناسب. بعضی دیگه کاملاً مربوط به طراحیان—مثل جابهجایی یک فیلد در صفحه یا تغییر نوع یک فیلد در کلاس.
اما در عمل، بیشتر تصمیمهایی که باهاشون روبهرو میشی، جایی بین این دو قرار میگیرن؛ یعنی در طیفی بین معماری و طراحی.
چرا باید برام مهم باشه که تصمیمم کجای طیف بین معماری و طراحی قرار میگیره؟ واقعاً اینقدر اهمیت داره؟
بله، خیلی مهمه. اینکه بدونی تصمیمت کجای طیف بین معماری و طراحی قرار میگیره، کمک میکنه بفهمی چه کسی باید مسئول اون تصمیم باشه. بعضی تصمیمها رو باید تیم توسعه بگیره (مثلاً طراحی کلاسهایی که یه قابلیت خاص رو پیادهسازی میکنن)، بعضی تصمیمها رو معمار سیستم باید بگیره (مثل انتخاب سبک معماری مناسب برای کل سیستم)، و بعضی تصمیمها هم باید بهصورت مشترک گرفته بشن (مثل جدا کردن یا ترکیب سرویسها).
تصمیمت کجای این طیفه؟
آیا تصمیمت استراتژیکه یا تاکتیکی؟
- تصمیمهای استراتژیک بلندمدتان و روی تصمیمهای آینده تأثیر میذارن
- تصمیمهای تاکتیکی کوتاهمدتان و معمولاً مستقل از بقیه تصمیمها هستن (هرچند ممکنه در چارچوب یه استراتژی گرفته بشن)
مثلاً اینکه خونهت چقدر بزرگ باشه، روی تعداد و اندازهی اتاقها تأثیر میذاره (استراتژیکه)، ولی انتخاب یه مدل خاص چراغ سقفی، تأثیری روی اندازهی میز ناهارخوری نداره (تاکتیکیه)
هرچی تصمیم استراتژیکتر باشه، بیشتر به سمت معماری متمایل میشه.
چقدر سخت یا زمانبره که تصمیمت رو اجرا یا تغییر بدی؟
تصمیمهای معماری معمولاً اجرای سختتری دارن و تغییرشون هم پرهزینهتره، در حالی که تصمیمهای طراحی راحتتر و سریعتر قابل اجرا یا تغییرن.
مثلاً اضافه کردن یه بخش جدید به خونه، کار پرزحمتیه و بیشتر به معماری مربوط میشه، ولی انداختن یه قالیچه توی اتاق، کار سادهایه و بیشتر به طراحی مربوطه.
آیا تصمیمت پای مصالحههای مهمی وسط میاره؟
مصالحهها همون مزایا و معایبیان که موقع تصمیمگیری باید سبکسنگینشون کنی. تصمیمهایی که پای مصالحههای مهمی در میون دارن، نیاز به زمان و تحلیل بیشتری دارن و معمولاً ماهیت معماری دارن. اما تصمیمهایی که مصالحههای کماهمیتتری دارن، سریعتر و با تحلیل کمتر گرفته میشن و بیشتر در حوزهی طراحی قرار میگیرن.
استراتژیک در برابر تاکتیکی، هرچه یک تصمیم استراتژیکتر باشه، بیشتر جنبهی معماری پیدا میکنه. این تفاوت مهمیه، چون تصمیمهای استراتژیک نیاز به فکر و برنامهریزی بیشتری دارن و معمولاً بلندمدت هستن.
میتونی تصمیمی رو تصور کنی که هیچجور مصالحهای توش نباشه، حتی خیلی کوچیک یا بیاهمیت؟
یه راهنمایی: اگه فکر کردی تصمیمی پیدا کردی که هیچ مصالحهای نداره، دوباره بگرد.
چطور میتونم تشخیص بدم که یک تصمیم بیشتر استراتژیکه یا تاکتیکی؟
سؤال خوبیست. برای اینکه بفهمی یک تصمیم بیشتر استراتژیکه یا تاکتیکی، میتونی از این سه سؤال کمک بگیری. یادت باشه، هرچه تصمیم استراتژیکتر باشه، بیشتر به معماری مربوط میشه.
۱- چقدر نیاز به فکر و برنامهریزی داره؟ اگه تصمیمگیری فقط چند دقیقه تا یکی دو ساعت طول بکشه، احتمالاً تاکتیکیست. اگه نیاز به چند روز یا چند هفته فکر و برنامهریزی داشته باشه، احتمالاً استراتژیکه (و بنابراین معماریمحورتره).
۲- چند نفر در تصمیمگیری دخیل هستن؟ هرچه افراد بیشتری درگیر باشن، تصمیم استراتژیکتره. اگه تصمیم رو خودت یا با یک همکار میگیری، احتمالاً تاکتیکیست. اگه نیاز به جلسات متعدد با ذینفعان مختلف داره، احتمالاً استراتژیکه.
۳- آیا تصمیمت مربوط به چشمانداز بلندمدته یا اقدام کوتاهمدت؟ اگه تصمیمت سریع و مربوط به چیزی موقتی یا قابلتغییره، بیشتر تاکتیکیست و به طراحی مربوط میشه. در مقابل، اگه تصمیمیست که مدت طولانی باهاش زندگی خواهی کرد، بیشتر استراتژیکه و به معماری مربوط میشه.
سطح تلاش: زیاد یا کم؟
معمار معروف نرمافزار، مارتین فاولر، یه جملهی معروف داره: «معماری نرمافزار همون چیزیه که تغییر دادنش سخته.»
میتونی از همین تعریف استفاده کنی تا بفهمی تصمیمت کجای طیف معماری تا طراحی قرار میگیره. هرچی تغییر دادن یه چیز سختتر باشه، بیشتر به معماری مربوطه. و هرچی راحتتر قابل تغییر باشه، احتمالاً به طراحی مربوطه.
نکته: سایت مارتین فاولر (martinfowler.com/architecture) منابع خیلی خوبی دربارهی معماری نرمافزار داره.
مثالها:
- اگه بخوای سبک معماری سیستم رو عوض کنی—مثلاً از معماری لایهای سنتی بری به سمت microservices—این کار سخت و زمانبره. پس این تصمیم در سمت معماری طیف قرار میگیره.
- ولی اگه فقط بخوای جای فیلدها رو توی یه صفحهی رابط کاربری تغییر بدی، این کار سادهست و سریع انجام میشه. پس این تصمیم در سمت طراحی طیف قرار میگیره.
مصالحههای مهم در برابر مصالحههای کماهمیت
بعضی تصمیمها پای مصالحههای مهمی وسط میارن—مثلاً انتخاب شهری که قراره توش زندگی کنی. بعضی دیگه مصالحههای کماهمیتتری دارن—مثل انتخاب رنگ فرش اتاق نشیمن.
میتونی از میزان اهمیت این مصالحهها کمک بگیری تا بفهمی تصمیمت بیشتر معماریمحوره یا طراحیمحور. هرچی مصالحهها مهمتر باشن، تصمیم بیشتر به معماری مربوط میشه. و هرچی کماهمیتتر باشن، بیشتر به طراحی مربوطه.
جمعبندی
حالا وقتشه که هر سه عامل رو کنار هم بذاریم تا بفهمیم یه تصمیم بیشتر معماریمحوره یا طراحیمحور. این تشخیص کمک میکنه تیمهای توسعه بدونن کی باید با معمار سیستم همکاری کنن و کی میتونن خودشون مستقل تصمیم بگیرن.
فرض کن تصمیم گرفتی بین سرویس ثبت سفارش و سرویس مدیریت موجودی، از پیامرسانی غیرهمزمان استفاده کنی تا واکنشپذیری سیستم موقع ثبت سفارش توسط مشتریها بیشتر بشه. چون واقعاً چرا باید مشتری منتظر بمونه تا موجودی کالاها بهروزرسانی بشه؟
بیاییم بررسی کنیم که این تصمیم کجای طیف معماری تا طراحی قرار میگیره.
اهمیت مصالحهها (Trade-offs)
استفاده از صف باعث میشه ثبت سفارش سریعتر انجام بشه، اما ممکنه موجودی کالاها بهموقع بهروزرسانی نشه و این موضوع باعث ایجاد سفارشهای معوق (back-order) بشه. این مصالحهها قابل توجهان و چون تأثیر زیادی روی رفتار سیستم دارن، تصمیم رو به سمت معماری سوق میدن.
نتیجه: از نظر مصالحهها، این تصمیم معماریمحوره است.
استراتژیک یا تاکتیکی بودن
این تصمیم نیاز به مشارکت افراد زیادی نداره و برنامهریزی بلندمدت هم درش دخیل نیست. بنابراین، بیشتر یه تصمیم تاکتیکی محسوب میشه.
نتیجه: از نظر استراتژی، این تصمیم طراحیمحوره است.
میزان تلاش
ارسال پیام به یه سرویس دیگه کار پیچیدهای نیست و توی معماریهای مدرن کاملاً رایجه. پس از نظر میزان تلاش، تصمیم سادهایه.
نتیجه: از نظر تلاش، این تصمیم طراحیمحوره است.
جمعبندی
اگه میانگین این سه عامل رو در نظر بگیریم، تصمیم استفاده از صف پیام یه تصمیمیه که هم جنبههای طراحی داره و هم معماری. اما چون مصالحههای مهمی درگیرشن، بهتره یه معمار نرمافزار در این تصمیم مشارکت داشته باشه.
خلاصه فصل
- معماری نرمافزار بیشتر به ساختار مربوطه تا ظاهر؛ در حالی که طراحی بیشتر روی ظاهر تمرکز داره تا ساختار.
- برای درک و توصیف معماری نرمافزار، باید از چهار بُعد استفاده کنی:
- ویژگیهای معماری (Architectural Characteristics)
- تصمیمات معماری (Architectural Decisions)
- اجزای منطقی (Logical Components)
- سبک معماری (Architectural Style)
- ویژگیهای معماری پایههای اصلی معماری نرمافزار رو تشکیل میدن. باید بدونی کدوم ویژگیها برای سیستم تو مهمترن تا بتونی مصالحهها رو تحلیل کنی و تصمیمات درستی بگیری.
- تصمیمات معماری مثل تابلوهای راهنما هستن که به تیم توسعه کمک میکنن محدودیتها و شرایط معماری رو درک کنن.
- اجزای منطقی مثل بلوکهای ساختمانی سیستم هستن. اینها کارهایی هستن که سیستم انجام میده و معمولاً از طریق کلاسها یا کد منبع پیادهسازی میشن.
- مثل معماری ساختمانها، در نرمافزار هم سبکهای معماری مختلفی وجود دارن. هر سبک از مجموعهای خاص از ویژگیهای معماری پشتیبانی میکنه، پس انتخاب سبک مناسب (یا ترکیبی از سبکها) برای سیستم خیلی مهمه.
- اینکه بدونی یه تصمیم معماریمحوره یا طراحیمحوره، مهمه چون مشخص میکنه چه کسی باید مسئول اون تصمیم باشه و چقدر اهمیت داره.
