خواندن ۱۸ دقیقه·۵ روز پیش

تمرین ۱ معماری نرم افزار : مروری بر ۲۰ مفهوم کلیدی

Chaos Engineering:

مهندسی آشوب راهکاری است که میتوانیم از طریق آن در سیستم نرم افزاری خود به هم ریختگی و عیوبی ایجاد کنیم تا شکست های احتمالی و پنهان را قبل از اینکه واقعا سیستم عیب کند نمایان کنیم .
این ابداع شرکت نتفلیکس بود ، نتفلیکس در سال 2008 از یک دیتابیس استفاده میکرد که اگر مشکلی در ان بوجود می امد کل سیستم مختل میشد و این اتفاق یکبار برای انها افتاد و 3 روز استریم ویدیو با مشکل جدی روبرو شد به این صورت که هیچکسی نمیتوانست ویدیویی از سایت ببیند . پس از این اتفاق به این نتیجه رسیدند که از وجود یک نقطه شکست جلوگیری کنند و معماری خود را به میکروسرویس تغییر دهند . اما با این حال به علت وجود وابستگی ها همچنان ممکن بود که با خرابی سرویس هایی کل سیستم مختل شود ، همچنین نمیتوانستند در محیط توسعه انرا تست کنند زیرا در دنیای واقعی خرابی های پیش بینی نشده و بی قائده ای همچون داغ کردن و سوختن سرور ، پر شدن دیسک ، قطعی شبکه و ... وجود دارند ، سر انجام مهندسان نتفلیکس ابزاری به نام Chaos Monkey ساختند که مانند میمونی بازیگوش به صورت تصادفی برخی از سرویس ها را غیرفعال میکرد، عملکرد سیستم پس از آشوب های ابتدایی تعریفی نداشت اما به مرور بهبود یافت و باعث مقاوت بیشتر سیستم شد .

Backend for Frontend:

در سال 2010 اکثر شرکت های بزرگ، محصولات نرم افزاری خود را برای کلاینت های دسکتاپ طراحی میکردند اما به مرور که بازار تلفن های همراه هوشمند رشد چشمگیری داشتند ، نیاز به توسعه کلاینت های موبایلی بسیار گسترده شد.
با توجه به اینکه کلاینت های موبایلی و دسکتاپ تفاوت هایی از جمله صفحه نمایش ، توان پردازشی ، اتصال شبکه متفاوت و ... داشند نیاز بود که اپلیکیشن های موبایلی و نرم افزار های دسکتاپ کمی تفاوت داشته باشند اما در ابتدا اپلیکیشن هایی که ساخته میشد از همان سرویس هایی استفاده میکرد که در نسخه دسکتاپ ارسال میشد که برای موبایل بهینه نبود و مشکلاتی مانند کندی را به همراه داشت.
از آن پس تکنیکی به نام Backend for Frontend یا BFF ابداع شد که در آن از سرویس هایی به نام BFF استفاده میکنیم که درخواست های سمت کلاینت یا سرور را مناسب با نوع آن کلاینت تنظیم و بهینه میکند (این با API Gateway متفاوت است ،API Gateway صرفا یک دروازه ای است که API ها را از خود عبور میدهد و مدیریت میکند ولی از منطق کلاینت ها آگاه نیست و نمیتواند آنها را تفکیک کند)، به این صورت دیگر نیاز نبود که بار اضافه وارد کلاینت های خاص شود و به بهبود سرعت آنها و هچنین استقلال توسعه کمک کرد.

AI4SE

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

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

SE4AI

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

MLOps

این مفهوم ترکیب ماشین لرنینگ و DevOps است.فرض کنید یک سامانه برای فروش بازی های ویدیویی داریم و مدلی برای این سامانه طراحی شده است که بر اساس سوابق خرید ها و جستجوی مشتریان به انها پیشنهاد خرید میدهد . ابتدا نیاز است که مدل ما train شود و باید داده های اولیه به ان بدهیم و نهایتا مدل یادگیری را انجام داده و به خوبی در ان سامانه کار میکند . حال فرض میکنیم که پس از گذشت مدتی بازی ها به سمت یک دسته بندی نوظهور و ترند متمایل شده اند و مشتریان بیشتر تقاضای خرید از ان دسته را دارند یا به هر نحو دیگری الگوی خرید انها دچار تغییر شده اما مدل طبق همان داده های قبلی پیشنهاد میدهد و نیاز است که مدل دوباره با داده های جدید آموزش ببیند، به روزرسانی شود و دوباره روی سامانه مستقر گردد. انجام دستی این کار به شدت کند است. اینجا جایی است که MLOps وارد می شود: ترکیب یادگیری ماشین و DevOps ، تا این چرخه را خودکار کند از گرفتن خودکار داده های جدید، تا آموزش مجدد مدل، تست خودکار و در نهایت استقرار سریع نسخه جدید بدون توقف سامانه و کوتاه شدن مدت استقرار ها یعنی میتوان گفت مدل دائما در حال یادگیری است

Infrastructure as Code (IaC)

در گذشته تمامی سامانه های نرم افزاری نیازمند این بودند که سرور هایشان را به صورت دستی نصب و راه اندازی میکردند به این صورت که ابتدا سرور های فیزیکی خریداری و سپس سیستم عامل ، نیازمندی ها و پیکربندی ها را به صورت دستی روی انها نصب و اعمال میکردند اما مشکل اینجا بود که اگر یک سرور خراب میشد دوباره باید کل مراحل قبل را به صورت دستی انجام میدادند که بسیار طاقت فرسا بود ، بعدا ها این ایده به وجود امد که زیرساخت های سامانه را مانند خود نرم افزار به صورت کد در بیاوریم و انها را به صورت خودکار و نسخه بندی شده روی گیت اعمال کنیم . IaC به این معنی است که زیرساخت های سامانه را بدون نیاز به عملیات های دستی به صورت خودکار انجام دهیم.

API Gateway & Service Mesh

در زمانی که سامانه های نرم افزاری از معماری یکپارچه (Monolithic) استفاده میکردند ، فقط یک نقطه تبادل پیام با کل سیستم وجود داشت یعنی تنها از یک طریق ، پیام بین سیستم و کلاینت رد و بدل میشد . با روی کار آمدن معماری میکروسرویس و تقسیم سیستم به تعداد زیادی سرویس کوچک ، کلاینت ها مجبور بودند با چندین سیستم تعامل داشته باشند که ارتباط شبکه ای کلاینت با سامانه را بسیار پیچیده میکرد ، اینجا بود که API Gateway ابداع شد و دروازه ای بود بین کلاینت ها و سیستم به این صورت که درخواست کلاینت ها به سرویس API Gateway وارد شده و به سمت سرویس مورد نظر هدایت میشدند .

با افزایش تعداد سرویس ها در معماری میکروسرویس ، ارتباط بین این سرویس ها نیز دچار پیچیدگی شد و همچنین از کار افتادن یک سرویس روی سرویس های دیگر تاثیر میگذاشت اینها باعث شد که Service Mesh پدید آید که امنیت و مدیریت ارتباط بین سرویس ها را فراهم میکرد. . در این روش یک پروکسی کنار هر سرویس قرار میدهیم که تمام ترافیک ورودی و خروجی از ان میگذرد که به ان سایدکار میگویند. ساید کار ها در یک هسته مرکزی به نام کنترل پلن مدیریت میشوند.

CQRS (Command Query Responsibility Segregation)

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

Event-Driven Architecture (EDA)

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

Serverless Architecture

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

API-first Approach

در روش های سنتی توسعه نرم افزار، روال کار به این صورت بود که ابتدا رابط کاربری و بخش های ظاهری برنامه طراحی می شد و بعد از ان برنامه نویسان سراغ نوشتن بک اند و دیتابیس می رفتند. در نهایت اگر نیاز بود که سامانه به سیستم دیگری متصل شود، یک رابط یا ای پی ای برای ان می نوشتند. اما این کار باعث می شد API ها کیفیت خوبی نداشته باشند و کار بین تیم های فرانت اند و بک اند کند شود. در رویکرد جدید API-first این روند برعکس شده است. در اینجا قبل از ساخت ظاهر، ابتدا توافق می شود که ارتباطات به چه صورت باشند و ورودی و خروجی ان ها مشخص می شود. با این کار تیم ها می توانند به صورت همزمان کار خود را شروع کنند و سامانه خیلی سریع تر اماده می شود.

Domain Driven Design

خیلی وقت ها در پروژه های نرم افزاری بزرگ، مشکل از برنامه نویسی نیست بلکه مشکل این است که برنامه نویسان زبان متخصصان ان کسب و کار را نمی فهمند. مثلا در یک سیستم بانکی، برنامه نویس ها فقط به دیتابیس و کد فکر می کنند ولی مدیران بانک در مورد مفاهیم مالی و حساب ها حرف می زنند. این اختلاف باعث می شود نرم افزار نهایی نیاز های واقعی کسب و کار را براورده نکند. طراحی مبتنی بر دامنه که توسط اریک اوانز در کتابش معرفی شده ، راه حلی برای این مشکل است. اریک درباره اهمیت شناخت دامنه اینگونه بیان کرده : اگر نمی دانی کسب وکارت واقعاً چگونه کار می کند، هر معماری هم بسازی، شکست می خورد.

در روشDomain Driven Design قبل از هرگونه کدنویسی، برنامه نویسان و متخصصان کسب و کار دور هم جمع می شوند و یک زبان مشترک می سازند. سپس کل معماری سیستم، اسم کلاس ها و ساختار نرم افزار دقیقا بر اساس همان مفاهیم واقعی دامنه مدل سازی می شود تا نرم افزار کاملا شبیه دنیای واقعی کار کند. لازم به ذکر است در پروژه های ساده که قوانین کسب و کاری سختی وجود ندارد استفاده از این روش لزومی ندارد.

Hexagonal architecture

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

Event Sourcing

در حالت عادی دیتابیس ها به این صورت کار می کنند که فقط وضعیت فعلی اطلاعات را ذخیره می کنند. مثلا وقتی موجودی حساب بانکی شما تغییر می کند، سامانه عدد قبلی را پاک می کند و عدد جدید را جایگزین می کند. مشکل این روش این است که ما تاریخچه تغییرات را از دست می دهیم و نمی دانیم این عدد چگونه به دست امده است. در این روش به جای ذخیره کردن وضعیت نهایی، تمام اتفاقات و رویداد هایی که باعث تغییر شده اند را به ترتیب ذخیره می کنیم. مثلا ثبت می کنیم که اول 500 تومان واریز شد، بعد 100 تومان برداشت شد. با این کار ما همیشه یک تاریخچه کامل از تمام اتفاقات سامانه داریم و اگر خطایی رخ دهد، می توانیم با اجرای دوباره رویداد ها، سیستم را به گذشته برگردانیم.

Low-code/No-code platforms

در سال های نه چندان دور، برای ساختن هر نرم افزاری حتما نیاز به تیم های بزرگ برنامه نویسی بود که باید خط به خط کد ها را با زبان های مختلف می نوشتند. این کار بسیار زمان بر و پر هزینه بود و افراد عادی نمی توانستند ایده های خود را سریع عملی کنند. با گذشت زمان پلتفرم های بدون کد (No-code) مثل joapp (برای ساخت اپلیکیشن اندروید) به وجود آمدند. این پلتفرم ها محیط هایی هستند که در آن ها افراد می توانند بدون نیاز به کدنویسی، و فقط با کشیدن و رها کردن اجزای گرافیکی، نرم افزار های خودشان را بسازند. این ابزارها باعث می شوند افراد معمولی که دانش برنامه نویسی ندارند هم بتوانند ایده هایشان را تبدیل به نرم افزار کنند و سرعت تولید سامانه ها برای کارهای ساده به شدت افزایش پیدا کند.

در کنار پلتفرم های بدون کد، دسته دیگری به نام پلتفرم های Low-code نیز وجود دارند. این پلتفرم ها برای توسعه دهندگان حرفه ای طراحی شده اند و به انها اجازه می دهند با نوشتن حداقل کد سرعت توسعه را چندین برابر کنند. تفاوت اصلی در این است که در Low-code هنوز هم می توان کد دستی نوشت، اما کارهای تکراری و زیرساختی توسط پلتفرم انجام می شود. یک مثال معروف از این دسته، OutSystems یا Microsoft Power Apps است که برای ساخت اپلیکیشن های سازمانی قدرتمند استفاده می شود.

Business Process Management Systems (BPMS)

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

Message Queue (such as Kafka and RabbitMQ)

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

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

Containers (eg., Docker) and Container orchestration (e.g., Kubernetes)

در گذشته یکی از بزرگترین مشکلات برنامه نویس ها این بود که نرم افزار روی سیستم خودشان به درستی کار می کرد اما وقتی ان را روی سرور اصلی می بردند، به دلیل تفاوت سیستم عامل یا نسخه کتابخانه ها، با ارور های مختلف مواجه می شدند. کانتینرها (مثل Docker) برای حل همین مشکل به وجود آمدند. ایده ساده است، شما نرم افزارتان را به همراه همه چیزهایی که برای اجرا نیاز دارد مثل کتابخانه ها، فایل های تنظیمات و ... داخل یک بسته ایزوله به نام ایمیج می گذارید. وقتی این ایمیج را اجرا می کنید، یک کانتینر ساخته می شود. کانتینرها در مقایسه با ماشین های مجازی خیلی سبک ترند و سریعا اجرا می شوند چون هسته سیستم عامل را با هم به اشتراک می گذارند . مزیت اصلی: یک کانتینر در هر جایی دقیقا یکسان اجرا می شود، چون همه وابستگی هایش را همراه خودش دارد. اما وقتی سیستم شما بزرگ می شود، مثلا به صد ها کانتینر می رسد، مدیریت دستی آن ها غیرممکن می شود. چه کسی قرار است هر ساعت چک کند که کدام کانتینر از کار افتاده و آن را دوباره راه بیندازد؟ چه کسی تصمیم می گیرد وقتی ترافیک زیاد شد، تعداد کانتینرها را افزایش دهد؟ کانتینرها چطور همدیگر را پیدا کنند؟ ارکستراسیون کانتینر مثل Kubernetes اینجاست تا همه این کارها را خودکار کند. کوبرنتیز مانند یک فرمانده مرکزی عمل می کند که روی یک کلاستر از سرورها نصب می شود و مدام وضعیت همه کانتینرها را رصد می کند و مسئول مدیریت انها است

Multi-Tenancy Architecture

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

Data Migration

در طول عمر یک سامانه نرم افزاری، مواقعی پیش می آید که مجبور می شویم سیستم های قدیمی را با سیستم های جدید جایگزین کنیم یا نوع دیتابیس را تغییر دهیم. در این زمان، اطلاعات ارزشمندی که طی سال ها در سیستم قدیمی جمع شده اند نباید از بین بروند و باید به سیستم جدید منتقل شوند. به این فرایند انتقال داده می گویند. این کار فقط کپی کردن ساده نیست، چون معمولا ساختار اطلاعات در سیستم جدید با سیستم قدیمی فرق دارد. بنابراین در این فرایند باید ابتدا داده ها استخراج شوند (Extract) ، سپس تمیز سازی شده و به فرمت سیستم جدید تبدیل شوند (Transform) و در نهایت با دقت بالایی در دیتابیس جدید لود شوند.(Load) این سه مرحله در مهاجرت داده با نام اختصاری ETL شناخته می شود. اشتباه در این مسیر می تواند باعث از دست رفتن اطلاعات مهم مشتریان شود.

منابع: