چهارچوب ها و معماری های توسعه سیستم ERP

مقدمه

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

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

معماریها و ساختارهای مورد نیاز برای توسعه یک سیستم جامع ERP را در هشت گروه موضوعی دسته­ بندی کرده و بیان رویکردهای مطرح شده در هر یک از موضوعات پرداخته ایم.

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

بخش اول : لایه بندی نرم افزار (Software Layering)

لایه بندی نرم افزار با هدف کاهش و مدیریت پیچیدگی نرم افزارهای بزرگ درحال توسعه خود به عنوان یک معماری در فرایند توسعه نرم افزار شناخته می­شود. این معماری موجب تقسیم وظایف میان اعضاء تیم توسعه، شفافیت رویکردهای توسعه و قابلیت نگهداری و پشتیبانی سریع و راحت در پروژه خواهد شد. یک معماری چندلایه نرم افزاری شامل لایه­های متفاوتی است و هر لایه مربوط به سرویس­ها یا وظایف مشخصی می­شود. از آنجایی که هر لایه از لایه های دیگر مجزاست تغییر در هر لایه ساده تر از کار با کل معماری خواهد بود. روشهای معماریهای مختلفی با هدف تقسیم بندی نرم افزار به لایه های مختلف ارائه شده است که مشهورترین آنها معماری سه ­لایه (Three-Layer Architecture) و معماری پیازی (Onion Architecture) می­باشند.

1. معماری سه لایه (Three-Layer Architecture)

در ابتدا لازم به توضیح است که در بیشتر مقالات این معماری با معماری سه ردیفه (Three-Tier) اشتباه گرفته می­شود که در آن سیستم نرم افزاری را به سه بخش، ردیف داده (Data Tier)، ردیف برنامه (Application Tier)و ردیف نمایش (User-Interface Tier) تقسیم بندی شده است. لذا در ابتدا به ارائه تعریفی درست از معماری سه لایه پرداخته می­شود. معماری سه-لایه در واقع یک تقسیم بندی و لایه بندی برای ردیف برنامه (Application Tier) در معماری سه ردیفه می­باشد که شامل 1-لایه های دسترسی به داده (Data-Access Layer)، 2-لایه قوانین تجاری (Business Rule Layer) و 3-لایه ارائه (Presentation Layer) می­باشد.

• 1) لایه دسترسی به داده (Data-Access Layer)

این لایه وظیفه فراهم سازی داده های و اعمال تغییرات داده­ای برروی پایگاه داده را بر عهده دارد که می­توان برای پیاده سازی آن از یکی از روشهای ساده دسترسی به داده یا از یکی از رویکردهای ORM استفاده کرد. این لایه عملیات درخواستی توسط لایه قوانین تجاری را برروی پایگاه داده انجام و نتایج درخواستی را برای آن فراهم می آورد. باید توجه داشت که هر گونه ارتباط با پایگاه داده یا به اصطلاح ردیف داده (Data Tier) از طریق این لایه صورت می­پذیرد.

• 2) لایه قوانین تجاری (Business-Rule Layer)

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

• 3) لایه ارائه (Presentation Layer)

این لایه برخلاف باور نادرست وظیفه نمایش اطلاعات و تعامل مستقیم با کاربر از طریق رابط گرافیکی کاربر (GUI) را ندارد و فقط نتایج حاصل شده از لایه منطق برنامه را با ساختار داده­ ای مناسب در اختیار ردیف نمایش (User-Interface) قرار می­دهد. از طرفی مقادیر دریافتی از ردیف نمایش را پس از اعتبارسنجی در اختیار لایه قوانین منطق قرار می­دهد. برای روشنتر شدن نقش لایه ارائه می­توان از نقش Api و Dto در معماری سرویس گرا و یا نقش Controllerو ViewModel در زیرساخت mvc برای طراحی یک نرم ­افزار تحت وب به عنوان مثالهایی از لایه ارائه نام برد.

ویژگیهای معماری سه لایه :

معماری سه لایه با تقسیم بندی مفهومی و پیمانه ای سازی از آنچه که در فرایند توسعه نرم افزار رخ می­دهد نگاه شفاف و روشنی برای تحلیل قوانین تجاری و پیاده ­سازی و ارائه نرم افزاری با قابلیت پشتیبانی بالا فراهم می ­آورد. لیکن طراحی لایه ­ها به صورت طبقه­ هایی برروی همدیگر باعث می شود که تغییر در روند پیاده ­سازی هر یک از لایه ها موجب انتشار تغییرات برروی سایر لایه­ ها گردد و استقلال پیاده سازی از هریک از لایه­ ها گرفته شود. در واقع علارغم جداسازی مفاهیم توسعه، با ارائه یک معماری «اتصال کامل» (Tightly coupled)، دغدغه وابستگی نحوه پیاده ­سازی آنها به همدیگر رفع نشده است که این امر کاملا مغایر با اصل «جداسازی دغدغه ها» (Separation of Concerns) می­­باشد

2. معماری پیازی (Onion Architecture)

معماری پیازی رویکرد دیگری بر نحوه لایه ­بندی ردیف برنامه (Application Tier)در ساختار سه ردیفه (Three Tier)دارد. این معماری روشی را ارائه می­دهد که قابلیت نگهداری، تست­ پذیری و توسعه­ پذیری نرم افزارها را به آسانی فراهم می‌سازد. معماری پیازی تاکید زیادی روی وابستگی ها و جدایی منطق، عملیات­ها، سرویس­ها و رابط کاربری را دارد و لایه­ بندی حول محور لایه هسته سیستم که در واقع دامنه (Domain) طراحی سیستم می ­باشد متمرکز است. دامنه یک سیستم که در حقیقت ماهیت آن را مشخص می­کند نقطه تلاقی و لازمه اصلی معماری پیازی می باشد و سایر لایه ­ها بر منبای دامنه و با مرکزیت آن شکل می­گیرند. در این معماری بر خلاف معماری سه لایه وابستگی به لایه داده وجود ندارد و تمرکز بر دامنه نرم ­افزار می باشد. پیاده سازی معماری پیازی به شدت به مفاهیم «معکوس سازی کنترلها» (Inversion Of Controls) و «تزریق وابستگیها» (Dependency Injection) تکیه دارد. در بسیاری از مقالات ارائه شده معماری پیازی، بجز لایه مرکزی دامنه (Domain Layer) شامل لایه سرویس برنامه (Application Service Layer)، لایه ارائه (Presentation Layer)، لایه زیرساخت (Infrastructure Layer) و لایه تست (Test Layer) نیز می باشد.

• 1) لایه دامنه (Domain Layer)

لایه دامنه که در مرکز این معماری قرار دارد نقطه شروع طراحی سیستم می باشد. در واقع بایستی در این لایه مشخص گردد سیستم چه رفتارهایی را دنبال می­کند تا که مدل عملیات آنها به صورت واسط (Interface) و ساختار داده­ های مورد نیاز دامنه به صورت اشیاء انتقال داده (Dto) مشخص گردد. الزامی است در این لایه هیچ نوع پیاده­ سازی از عملیاتها صورت نمی­ گیرد. پیاده سازی این قراردادها در لایه­ های دیگر خواهد بود.

• 2) لایه سرویس برنامه (Application Service Layer)

لایه سرویس برنامه که از آن به عنوان لایه قوانین یا منطق تجاری (Business-Rule Layer) نیز یاد می­شود لایه ای برای پیاده­ سازی و اعمال قوانین یا منطق تجاری سیستم و پیاده سازی آن هاست. این لایه واسطی میان لایه های زیرساخت، ارائه و دامنه را فراهم می­آورد.

• 3) لایه زیرساخت (Infrastructure Layer)

لایه زیرساخت که از آن به عنوان «لایه مخرن» (Repository Later) نیز یاد می­شود. لایه زیر ساخت بخش پیاده سازی زیرساختهای داده ­ای و ارتباطات با داده یا سرویسهایی است که خارج از دامنه پروژه می­باشند. استقلال کامل لایه زیر ساخت در پیاده­ سازی شرایطی را فراهم می ­آورد که هر گونه تغییر در آن مانع از انتشار تغییرات به سایر لایه­ ها گردد.

• 4) لایه ارائه (Presentation Layer)

لایه ارائه را میتوان به عنوان لایه پوسته پیاز در نظر گرفت این لایه نیز مشابه لایه هم نام خود در معماری سه لایه وظیفه نمایش برای کاربر را ندارد و فقط اعتبارسنجی، شکل­ دهی و انتقال داده معماری با ردیف نمایش (User-Interface) را فراهم می­ آورد.

• 5) لایه تست (Test Layer)

لایه تست نیز لایه مستقل دیگری است که برروی لایه دامنه و لایه سرویس برنامه طراحی می­گردد و در صورت نیاز از طریق لایه زیرساخت ارائه شده و یا پیاده ­سازی­ های جعلی(Fake) برای زیرساخت منطق تجاری و رویه­ های سیستم را ارزیابی و تست می­کند.

ویژگیهای معماری پیازی :

معماری پیازی با تاکید برروی دامنه سیستم، اساس سیستم را در برابر تغییرات زیرساختی محافظت می­کند. مهمترین دلیل برای ایجاد چنین معماری ای، نیازمندی به ساختاری است تا قابلیت نگهداری برنامه ها در دراز مدت را فراهم نماید. این معماری به صورت کامل رعایت اصل «جداسازی دغدغه ها» (Separation of Concerns) را در سرتاسر سیستم فراهم می­ آورد. نکته حائز اهمیت در رابطه با معماری پیازی این است که این معماری برای پروژه های ساده و سبک اصلا مناسب نیست بلکه برای برنامه های بزرگ با رفتارهای پیچیده مناسب می باشد. معماری پیاز یکی از بهترین معماری های موجود برای پیاده سازی یک سیستم قابل تست (Testable) و قابل اطمینان (Dependable) است.

جمع‌بندی
به منظور­ پیاده ­سازی یک سیستم جامع ERP که فرایندهای کاری در آن مشخص شده است بهتر است از معماری پیازی بهره ­گرفته شود زیرا با توجه به مدت حیات یک سیستم ERP احتمال تغییر در دامنه عملیاتها کم است درحالیکه با سرعت در تغییر زیرساختهای تکنولوژی و نیاز به تغییر در پیاده­ سازی آنها بهتر است از رویکردی استفاده گردد تا تغییرات تاثیر کمتری بر سایر بخشها را داشته باشند. این موضوع در پروژه ­های مهاجرت یا تغییر تکنولوژی به دلیل احتمام در جداسازی «دغدغه های زیرساخت پایگاه داده» از «دغدغه تغییرات تکنولوژی توسعه نرم ­افزار»، نقش مهمتری خواهد داشت.

چگونه پیاده ­سازی کنیم
معماری پیازی یک چارچوب مفهومی برای طراحی سیستم می ­باشد لذا برای پیاده­ سازی آن بایستی حداقل با مفاهیم تکنولوژی 1-تزریق وابستگی­ها (Dependency Injection) و 2-پیاده ­سازی واسطها (Interface) آشنایی و از آنها استفاده کنید. بهره گیری از معماری پیازی مستقل از زبان برنامه نویسی یا چارچوب تکنولوژی می باشد.

بخش دوم : پیکربندی نرم افزار سازمانی (Enterprise Application Configuration)

طراحی و توسعه یک سیستم جامع سازمانی همواره با چالشهای توسعه­ پذیری، مقیاس­ پذیری و نگهداری روبرو بود. با افزایش نقش نرم افزارها و نیاز به تکنولوژی میزان دسترس­ پذیری نیز به چالشهای موجود افزوده شد. در سالهای گذشته هرگاه سخن از تولید و توسعه یک سیستم جامع به میان آمده، همواره نگاه پیکربندی رسیدن به یک سیستم یکپارچه (Monolithic) و مجتمع (Integrated) بوده است. لیکن با پدیداری مفاهیم جدیدی مانند DevOps با هدف ایجاد تعامل بیشتر در حوزه توسعه نرم افزار، تضمین کیفیت و کنترل عملیات، که باعث انتقال سریع نرم‌افزار از توسعه به عملیات خواهد شد، سیستمهای یکپارچه ارزش و اهمیت خود را از دست دادند. حال در شرایط فعلی سه گزینه و راه حل برای پیکربندی و سازماندهی نرم­ افزارهای جامع را در پیش رو داریم که شامل موارد زیر می­شود. 1-معماری یکپارچه (Monolithic Architecture) 2-معماری سرویسگرا (Service-Oriented Architecture) 3- معماری ریزخدمات (Micro-Service Architecture)، که در ادامه به تشریح آنها پرداخته می شود.

1. معماری یکپارچه (Monolithic Architecture)

معماری یکپارچه همان رویکرد توسعه راه حلی است که هدف آن دستیابی به سیستمی می­باشد که به شکل یک نرم افزار یکپارچه، اجرا و پاسخگوی تمامی نیازهای یک مجموعه باشد. در این معماری نرم افزار به صورت یک پلتفرم واحد توسعه می­ یابد. یک پلتفرم واحد اغلب دارای یک پایگاه داده مشترک برای تمامی بخشهای سیستم می­ باشد. در این رویکرد سیستم نرم ­افزاری فقط از دیدگاه رده ­بندی (Tiring) بخش بندی شده و در بیشترین حالت می­تواند از طریق سه سرویس دهنده داده، برنامه و نمایش که به صورت متوالی به هم سرویس می­دهند توزیع شده باشد. بایستی در نظر داشت که «معماری یکپارچه» قدیمی نیست، و هنوز هم در برخی موارد عالی عمل می­کند. معماری یکپارچه راحت است و به راحتی توسط تیم ها و پروژه های کوچک پذیرفته می­شود. در بسیاری از استارت آپ ها برای توسعه از معماری یکپارچه استفاده می شوند و زمانی که ماژول ها به هم وابسته و مرتبط هستند، گزینه مناسبی خواهد بود.

• مزایا

معماری یکپارچه به راحتی قابل توسعه و استقرار است، و نرم­ افزارهای یکپارچه به‌ نوعی عملکرد بهتر و سریع‌تری دارند، ماژول‌ها به هم نزدیک هستند که یک ساختار واحد، دسترسی آنها به یکدیگر را بسیار سریع می‌کند.

• معایب

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

2. معماری سرویسگرا (Service-Oriented Architecture)

معماری سرویس‌گرا یا SOA رویکردی برای توسعه نرم‌افزاری می­ باشد که در آن برنامه متشکل از عواملی گسسته و با «وابستگی ضعیف» (Loosely Coupled)، عملکرد مورد نیاز سیستم را انجام می‌دهند. SOA دو نقش اصلی دارد: «ارائه دهنده خدمات» و «مصرف کننده خدمات». هر دوی این نقش ها را می توان توسط یک عامل نرم­افزاری ایفا کرد. مفهوم SOA در موارد زیر نهفته است: یک برنامه کاربردی می تواند به گونه ای طراحی و ساخته شود که ماژول های آن به طور مجتمع یکپارچه شده و به راحتی قابل استفاده مجدد باشد. هر سرویس عملکردی را در سطح انتزاع ارائه می دهد، به عنوان یک جعبه سیاه در نظر گرفته می شود، که در آن از سربار توسعه جدید جلوگیری می شود. خدمات انتزاعی هستند و می توانند بر روی هر فناوری توسعه یابند. ارتباط بین آنها را می توان با استفاده از یک نقطه اتصال مرکزی به نام Enterprise Service Bus انجام داد. ESB از تمام خدمات مراقبت می­کند و به آنها کمک می کند تا با یکدیگر تعامل داشته باشند.

• مزایا

معماری سرویس­ گرا امکان استفاده مجدد از سرویسها را فراهم می­ آورد. امکان پیاده ­سازی مستقل و تنوع در پیاده ­سازی آنها را بوجود می­آورد. قابلیت نگهداری بهتر و اطمینان بالاتری دارد. ماژول‌ها در قالب سرویسهای مستقل امکان توسعه موازی پیدا می­کنند.

• معایب

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

3. معماری ریزخدمات (Micro-Service Architecture)

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

• مزایا

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

• معایب

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

جمع‌بندی
همانگونه که لایه­ بندی یک سیستم نرم افزاری با نگاه افقی آن بر مبنای مفاهیم توسعه تقسیم­بندی می­کند، پیکربندی یک سیستم جامع نیز با یک نگاه عمودی سعی در پیمانه­ای سازی(Modularity) و بخش­بندی آن دارد. معماری ریزخدمات مناسب سیستمهایی در مقیاس بزرگ (Large Scale) می­باشد که احتمالا گستره جغرافیایی بزرگی را پوشش می­دهند و توقف خدمات در آنها قابل پذیرش نبوده و عواقب ناگواری ایجاد می­کند. رویکرد سرویسگرا برای سیستم‌های پیچیده سازمانی مناسب‌تر است که تعاملات میان سیستمها اهمیت دارد و بایستی شرایطی برای توسعه و نگهداری موازی فراهم کرد. یک رویکرد یکپارچه نیز برای سیستمهای کوچک و یا تیمهایی با افراد و زمان محدود مناسب می­باشد. لذا با توجه به ماهیت سیستمهای ERP توصیه می­شود پس از کسب داش کافی در حوزه معماری سرویس­گرا، از آن برای طراحی سیستم استفاده گردد.

نکته مهم
در ادبیات مهندسی نرم­افزار از معماری­ها و مدلهای طراحی بسیاری نام برده می­شود که علاوه بر موارد مطرح شده می­توان از «معماری تمیز» (Clean Architecture)، «معماری رویداد-گرا» (Event-Driven Architecture)، مدل «جداسازی وظایف پرس­وجو و فرمان» (Command Query Responsibility Segregation) یا مدل «توسعه آزمون محور» (Test Driven Development) نیز اشاره کرد. بدیهی است این معماری­ها یا مدلها همواره در تضاد با یکدیگر نمی­باشند و هر یک از آنها امکان گزینش در موضوعی را فراهم می­آورد. بنابرین اگرچه در موضوع لایه­ بندی ناچار به انتخاب یکی از معماریهای پیازی یا سه­ لایه خواهیم بود لیکن می­توان درکنار آن، در موضوع پیکربندی، معماری دیگری را از بین موارد مطرح شده انتخاب و درکنار معماری لایه­ بندی به کار برد. و یا حتی برای تاکید در بهره ­گیری از رویکردهای کد تمیز (Clean Code) از «معماری تمیز» بهره جست و اینها منافاتی باهم نخواهند داشت. بنابراین ممکن است پروژه­ای تعریف گردد که همزمان از «معماری پیازی»، «معماری تمیز» و «معماری ریزخدمات» به همراه مدل «توسعه آزمون محور» در آن استفاده شده باشد.

چگونه پیاده­ سازی کنیم
معماری سرویس­گرا به دلیل تقسیم­بندی سیستم به پیمانه­های منطقی نیازمند نگاه تحلیلی برای پیاده ­سازی می­­باشد بنابرین می­توان از تکنیک «طراحی دامنه محور» (Domain Driven Design) برای بخش بندی سیستم و مفاهیم Web Api برای پیاده ­سازی سرویسها استفاده کرد. از کتابخانه­ هایی مانند Swagger یا ابزارهایی مانند Postman برای بررسی و نمایش ساختار سرویس­ها نیز می­توان استفاده کرد.

بخش سوم : ارتباط با پایگاه داده (Data Access & ORM)

دسترسی به داده و پایگاه داده مهمترین بخش از یک سیستم ERPمی باشد که با توجه به زیرساختها و طراحی شی گرایی لازم است از یکی از رویکردهای نگاشت شی-رابطه ای (ORM) استفاده گردد. ORM یک تکنیک برنامه نویسی برای نگاشت داده های پایگاه داده رابطه ای و زبان های برنامه نویسی شی گرا است. که در واقع یک "پایگاه داده شی مجازی" ایجاد می­کند. همواره دو رویکرد اساسی در نحوه مواجهه با ORMوجود دارد که مسیر طراحی و پیاده ­سازی سیستم را مشخص می­کند. رویکردهای کد-اول (Code-First) و داده-اول (Data-First) که در رویکرد کد-اول به منظور در طراحی سیستم ابتدا کلاسها و ساختار شی­گرایی برنامه شکل می­گیرد سپس بر اساس آن پایگاه داده طراحی می­گردد. در رویکرد دوم پایگاه داده طراحی و سپس ساختار مدل شی­گرایی برنامه از روی آن شکل می­گیرد.

1. طراحی کد-اول (Code-First)

در رویکرد Code First، کلاس‌ها ابتدا با تمرکز اولیه روی دامنه یک برنامه ایجاد می‌شوند. می­توان بدون طراحی پایگاه داده، شروع به ایجاد کلاس ها و ویژگی های مورد نیاز کرد. سپس یا از طریق ORM یا بصورت دستی جداول و پایگاه داده را بر اساس آن ایجاد شود. باید در نظر داشت که Code First یک رویکرد بسیار محبوب است و کنترل کاملی بر روی کد به جای فعالیت پایگاه داده دارد. در این روش می‌توان تمامی عملیات پایگاه داده را از طریق کد برنامه انجام از اعمال تغییرات دستی به پایگاه داده اجتناب کرد. در این مورد باید موجودیت های POCO را به عنوان مدل داده ایجاد کنید.

مزایا :

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

معایب :

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

2. طراحی داده-اول (Data-First)

در روش Data-Firstکه به آن Database-First یاReverse-Engineeringنیز گفته می شود بایستی اول پایگاه داده در یک DBMS ساخته شود و و سپس از طریق Scaffold یا به صورت دستی ساختار کلاسها طراحی شود. اگر هدف کار بر روی یک پروژه مهاجرت یا تغییر تکنولوژی می­باشد که قبلاً یک پایگاه داده در حال تولید یا استفاده دارد یا اگر سیستم تولیدی یک برنامه پایگاه داده محور است، در این صورت باید از رویکرد اول پایگاه داده یا مهندسی معکوس استفاده شود. بعلاوه در شرایطی که تغییرات مکرر بالقوه ای در پایگاه داده رخ میدهد اهمیت استفاده از این رویکرد بیشتر ظهور پیدا می­کند. در رویکرد داده اول مهمترین نکته دریافت و ارسال درست اطلاعات و تغییرات به پایگاه داده و حفظ صحت داده است و برنامه محدودیت یا الگوی خاصی برای تعریف پایگاه داده در نظر نمی­گیرد.

مزایا :

• پایگاه داده شما براحتی ساخته شده و به آسانی ویرایش میشود
• جهت ایجاد ارتباط بین جداول ، انتخاب کلید اصلی ، نوشتن Store Procedure نیازی به کدنویسی نمی باشد
• مناسب برای پروژه های مهاجرت و شرایطی که قبل از شروع کار پایگاه داده در دسترس می باشد
• مناسب برای سیستمهای بزرگ و پیچیده که نیازمند عملیات در سطح پایگاه داده و مدیریت فعال و تغییرات پایگاه داده را دارد

معایب :

• به روزرسانی مدل و کنترل تغییرات برروی پایگاه داده بایستی به صورت مستمر انجام پذیرد تا اثر نامطلوبی بر روند برنامه نداشته باشد.
• به دلیل جدا بودن کلاسها از پایگاه داده و امکان وجود رویه های ذخیره شده در پایگاه داده در برخی موارد امکان درک صحیح از فرایند عملیاتی پیچیده خواهد شد و سوابق تغییرات در سیستمهای مدیریت تاریخچه کد (Source Control) قابل ردگیری نخواهد بود.
• اگر تغییری در پایگاه داده ایجاد شود، کلاس مدل باید با همان ویژگی ها گسترش یابد
• ایجاد و مدیریت کلیدها و روابط نیاز به کدگذاری بیشتری دارد

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

چگونه پیاده­ سازی کنیم
به منظور پیاده ­سازی ارتباط با پایگاه داده می­توان از کتابخانه ­های مختلفی مانند Entity Framework ، Dapperیا Hibernate استفاده کرد که از میان آنها ابتدا Dapper و سپس Entity Framework برای پیاده سازی رویکرد داده-اول مناسب می­باشند.

بخش چهارم : احراز هویت (Authentication)

احراز هویت به این سوال اشاره داد که شما چه کسی هستید؟ احراز هویت فرایند شناسایی منحصر به فرد سرویس گیرنده‌های نرم‌افزار کاربردی است که ممکن است کاربران نهایی یا سایر سرویس‌ها و فرایندهای برنامه‌نویسی باشند.

سیستمهای تحت وب که بر پایه پروتکل httpبنا شده اند از مبانی این پروتکل پیروی میکنند و این پروتکل ارتباط بین کلاینت و سرور را برقرار میکند، همچنین این پروتکل وضعیت کاربر فعال را درون خود حفظ نمیکند(stateless) و نیاز به اعتبارسنجی مجدد دارد. به وسیله روشهای احراز هویت ما قادریم که به سرور بفهمانیم که در حال حاضر داخل حساب کاربری خود هستیم و به سیستم دسترسی داشته باشیم. در پیاده سازی احراز هویت در پرتکل http استفاده از sessionو یا استفاده از token برای غلبه‌ بر این مشکل در درخواست‌ها استفاده میشود. فهمیدن مکانیزم احراز هویت توسط توسعه‌دهندگان به سبب ایجاد یک برنامه کاربردی قابل اطمینان و همچنین نگهداری اطلاعات کاربران بصورت امن، بسیار حائز اهمیت است.

1. احراز هویت مبتنی بر جلسه (Session Base)

زمانی که کاربر وارد حساب خود در یک سیستم تحت وب می‌شود، سرور یک Sessionبرای او ایجاد میکند و اطلاعات آن را در حافظه خود ذخیره میکند. پس از آن سرور، Session Idحاصل شده را در یک Cookie در جستجوگر (Browser) کاربر ذخیره میکند. پس از آن، تا زمانی که کاربر توسط سرور شناسایی شود، برای هر درخواست از Cookieذخیره شده در جستجوگر او استفاده میشود. در این صورت سرور قادر خواهد بود که Session Idذخیره شده در Cookie را با اطلاعات Session ذخیره شده در حافظه سرور مقایسه کند تا کاربر را بصورت دقیق شناسایی و پاسخ را ارسال کند. همچنین در زمان خروج از حساب کاربری، Session ساخته شده، از پایگاه داده حذف خواهد شد.

ویژگیهای احراز هویت مبتنی بر جلسه :

• معیارهای امنیتی

به طور پیش فرض، احراز هویت مبتنی بر کوکی از حفاظت بالایی در برابر حملات برخوردار نیست و عمدتا در برابر XSS و CSRF آسیب پذیر است. البته می‌توان با تغییر درهدرهای Cookie تا حدیدر برابر چنین حملاتی محافظت شوند.

• معمولا روی یک دامنه کار می‌کند

کوکی‌ها فقط در یک دامنه واحد کار می‌کنند، مگر اینکه آن را به طور خاص پیکربندی کرده باشید.

• برای APIها مناسب نیست

اگر قرار است سیستم ارائه شده بر پایه API طراحی گردد ، کوکی‌ها راه حل مناسبی نیستند.

• وجود مشکلات مقیاس پذیری

سرور مسئول پیکربندی کوکی است و ما باید Sessionها را در پایگاه داده برای هر کاربر ذخیره کنیم.

• مناسب برای ذخیره اطلاعات اضافی

از آنجا که این روش Session‌های جداگانه‌ای را برای هر کاربر در نظر می‌گیرد، بنابراین می‌توانیم داده‌های متصل به Sessionها را ذخیره کنیم. با بهره گیری از Cookie‌ها و Sessionها می‌توانیم داده‌های خاصی مانند شخصی­سازی کاربر و کنترل دسترسی را ذخیره کنیم. سپس به ما اجازه می‌دهد تا از آن برای درخواست‌های بعدی استفاده نماییم.

• می‌تواند دسترسی به کوکی را در مرورگر محدود کند

از آنجا که کوکی ویژگی HTTP-Only را ارائه می‌دهد، می‌توانیم دسترسی جاوااسکریپت را برای آن محدود کنیم. علاوه بر این از هرگونه دسترسی به کوکی با حملات Cross-Site جلوگیری می‌کند.

2. احراز هویت مبتنی بر توکن (Token Base)

در احراز هویت برپایه توکن، سرور یک توکن امضا (sign) شده بر اساس کلید خصوصی را ایجاد و آن را به کلاینت ارسال میکند. توکن در سمت کلاینت ذخیره میشود و به عنوان headerدر هر یک از درخواست‌ها ارسال میشود. پس از آن سرور توکن را رمزگشایی کرده و در صورتی که توکن معتبر باشد، درخواست را پردازش و پاسخ آن را ارسال میکند. همچنین زمانی که کاربر از حساب خود خارج میشود، توکن در سمت کلاینت بدون هیچ تعاملی با سرور از بین میرود. زمانی که ما در مورد احراز هویت بر اساس توکن صحبت میکنیم، در واقع اشاره اصلی ما به JWT یا همان JSON Web Token میباشد که امروزه به طور گسترده در بسیاری از سیستمها استفاده میگردد و عملا به یک استاندارد در زمینه احراز هویت تبدیل شده است.

ویژگیهای احراز هویت مبتنی بر توکن :

• یک مکانیزم stateless و مقیاس­پذیر

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

• مسائل امنیتی

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

• مناسب برای ذخیره اطلاعات اضافی

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

• قابلیت پیاده سازی Single-Sign-On

ویژگی SSO یک سرویس متمرکز تایید هویت است که در آن کاربر تنها با استفاده از یک حساب کاربری (نام کاربری و رمز عبور) از طریق احراز هویت در «سرویس­ دهنده احراز هویت» (Authentication Server) می­تواند به چندین برنامه یا سایت دسترسی داشته باشد. احراز هویت مبتی بر توکن شرایط SSOو همچنین «احراز هویت شخص ثالث» Third-Party Authenticationرا فراهم می­سازد. در «احراز هویت شخص ثالث» برنامه می تواند برای تائید هویت کاربر از سرویسهای احراز هویت عمومی بهره ببرد

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

چگونه پیاده­ سازی کنیم
برای پیاده­ سازی احراز هویت کتابخانه ­های بسیاری ارائه شده است که برای رویکرد مبتنی بر جلسه از کتابخانه AspNetIdentity و برای رویکرد مبتنی بر توکن از کتابخانه JwtBrearer می­توان استفاده کرد.

بخش پنجم : مجوزهای دسترسی (Authorization)

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

1. اعطای مجوزهای دسترسی به روش نقشها (Role Base)

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

2. اعطای مجوزهای دسترسی به روش ادعاها (Claim Base)

ادعاها می توانند گسترده تر از یک نقش باشند. می توان در مورد ادعا به عنوان یک برچسب فکر کرد. به عنوان مثال، می توانید یک فرد را با عناوین {دوستانه}، {سابقه بالای 5 سال}، {ساکن تبریز}، {بزرگسال 18 سال} و غیره در نظر گرفت. در ضمن از نظر فنی، نقش را نیز می توان به عنوان یک ادعا مطرح کرد.

مقایسه مجوزهای دسترسی مبتنی به روش نقشها با روش ادعاها:

• با نقش ها فقط می توان نوع کاربری که با آن کار می کنید را شناسایی کرد لیکن با ادعاها می توانید زیرمجموعه ای از اطلاعات کاربردی در مورد کاربر داشته باشید.
• ادعاها جفت های کلید-مقدار ساده­ای هستند که میتوان آنها را به عنوان ویژگی­های یک کاربر در نظر گرفت. اما نقش­ها فقط کلید هستند و مانند ادعا مقداری ندارند.
• کلید نقشها معمولا بر روی سرویس دهنده نگهداری می­شود لیکن در رویکرد ادعا مقادیر ادعا در اختیار کاربر است و کاربر می­تواند از طریق مقدار ادعایی که از یک سرویس دهنده دریافت کرده است در سرویس دیگری صاحب نقش و دسترسی باشد.

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

بخش ششم : طراحی رابط کاربری (User-Interface Design)

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

1. طراحی رابط کاربری وب (Web UI Design)

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

2. طراحی رابط کاربری بومی (Native UI Design)

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

اگر هدف و مقصد ما از رابط کاربری، طراحی یک سیستم مبتنی بر وب و پروتکل http می­باشد تکنولوژی­ها و ابزارهای زیادی برای این کار وجود دارند که بصورت کلی در یکی از دو گروه «تفسیر سمت سرویس­ دهنده» (Server Side Rendering) و «تفسیر سمت سرویس­ گیرنده» (Client Side Rendering) تقسیم می­شود. لازم به توضیح است که در اینجا منظور از تفسیر (Rendering) فرآیندی است که داده ­های خروجی یک سیستم را با یک الگو (Template) ترکیب می­کند و یک فایل HTML را به عنوان خروجی ارائه می دهد که مرورگر می تواند از آن استفاده کند.

1. تفسیر سمت سرویس دهنده (Server Side Rendering)

هر زمانی که از یک وب سایت یا سیستم تحت وب بازدید می­شود، مرورگر آدرس صفحه یا محتوایی را از سرویس دهنده درخواست می کند. در رویکرد SSR صفحه یا محتوای درخواستی در سمت سرور تولید و نتیجه به صورت الگوی HTML برای نمایش به کاربر ارسال کند. حال اگر تصمیم دارید از صفحه دیگری نیز بازدید کنید، مرورگر شما یک بار دیگر درخواست صفحه جدید را به سرویس دهنده ارسال آن را دریافت و به شما نمایش می­دهد.

• مزایا

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

• معایب

ایراد اصلی تفسیر در سمت سرویس ­دهنده پیاده­ سازی پیچیده و افزایش مدت زمان پاسخگویی می­باشد که در اغلب موارد ناشی از انتقال حجم زیادی از محتوی HTML در لابه­لای درخواستها و پاسخها به سمت سرویس دهنده است.

2. تفسیر سمت سرویس ­گیرنده (Client Side Rendering)

وقتی در مورد تفسیر سمت سرویس ­گیرنده صحبت می­شود، فرایند تولید فایل یا صفحه HTML در سمت گیرنده صورت می ­پذیرد. مرورگر معمولا در اولین درخواست خود از سرویس­ گیرنده فایلهایی را در قالب دستورات JavaScript دریافت می­کند که این دستورات وظیفه شکل ­دهی به صفحات مورد نیاز کاربر را دارند. اگر صفحه نیاز به گرفتن داده یا اطلاعاتی از سمت سرویس ­دهنده باشد این اطلاعات از طریق سرویسهای وب که بصورت Api فراهم شده اند در دسترس خواهد بود. تفسیر سمت سرویس­ گیرنده رویکرد نسبتا جدیدی برای ارائه نرم افزارهای است که به اصطلاح به آنها «برنامه ­های تک صفحه ­ای» (Single Page Application) نیز گفته می­شود که با افزودن برخی ویژگیها و سرویس­ها قادر خواهیم بود نرم ­افزاری داشته باشیم که یک تجربه اجرایی بومی (Native) را برای ما ایجاد کند. به این نوع نرم ­افزارها «برنامه ­های وب پیشرو» (Progressive Web App) نیز می گویند.

• مزایا

«تفسیر سمت سرویس گیرنده» به مشابه یک برنامه وب پیشرو یک تجربه کاربری جذاب و مشابه برنامه بومی را روی دستگاه برای ما ایجاد میکند. اگر سیستم مورد نظر تعاملات داده­ای زیادی با سرویس­ دهنده برقرار می­کند CSR گزینه مناسبی برای پیاده خواهد بود. در حالت کلی ساخت یک برنامه وب (و نه یک وب سایت) از طریق رویکردهای CSR نتایج مطلوبی حاصل خواهد کرد.

• معایب

بزرگترین ایراد طراحی CSR عدم شناسایی محتوی آن توسط موتورهای جستو می باشد و دلیل آن شکل گیری صفحات بعد از بارگذاری اولیه آنها می­باشد. مشکل دیگر احتمال ضعیف بودن سرویس ­گیرنده و بروز مشکلات در سرعت پردازش و محدودیت در اجرای دستورات JavaScript می­باشد.

جمع‌بندی
در توسعه یک سیستم ERPبا طیف وسیعی از نیازمندیها موجب طراحی رابط­ های کاربری مختلفی در ساختارهای بومی و وب خواهد شد. لیکن به عنوان رابط کاربری اصلی و عمده سیستم با توجه به ماهیت سیستم که یک نرم ­افزار کاربردی بوده و تعاملات داده­ای زیادی با سرویس ­دهنده خواهد داشت بهره­ گیری از رویکردهای توسعه وب و تفسیر در سمت سرویس­ گیرنده «تجربه کاربری» (User Experience) بهتری را برای کابران سیستم حاصل خواهد کرد.

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

بخش هفتم : گزارشات، خروجی­ها (Reports, Outputs)

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

1. گزارشات مبتنی بر فایل (File Base Reports)

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

2. گزارشات مبتنی بر سرویس (Service Base Reports)

گزارشات مبتنی بر سرویس گزارشاتی هستند که خروجی آنها توسط سرویسهای تحت وب فراهم می­شوند و از نظر اجرایی از برنامه کاربردی مستقل هستند. به دلیل اساس سرویس محور بودن آنها در هر بخش از سیستم به راحتی می­توان از آنها بهره جست.

3. بهره­ گیری از گزارش ­ساز (Report Generators)

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

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

بخش هشتم : پایگاه داده (Data Base)

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

از مزایای انتخاب نوع پایگاه داده مناسب برای سازمان می‌توان به موارد زیر اشاره کرد:

• تسهیل ذخیره سازی اطلاعات مرتبط و لازم به شیوه ای سازگار
• کمک به نرمال‌سازی، کاهش افزونگی داده ها، جلوگیری از تکرار داده ها و کاهش حجم پایگاه داده
• ساده‌سازی اجرای پرس و جوهای ارسال شده برای واکشی داده ها و همچنین سرعت بخشیدن به اجرا آنها
• تسهیل وظایف مربوط به نگهداری پایگاه داده

همچنین عواملی که هنگام انتخاب پایگاه داده مناسب برای سازمان باید در نظر گرفته شود، به موارد زیر هستند:

• اندازه داده ای که باید ذخیره شود
• قابلیت دسترسی پذیری به داده ها
• ساختار داده‌ها
• امنیت داده‌ها

با توجه به موارد ذکر شده، انواع اصلی پایگاه‌های داده به شرح زیر هستند:

1. پایگاه داده‌های رابطه‌ای (Relational Databases)

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

از پایگاه‌های داده‌ی رابطه‌ای می‌توان به CockroachDB، Firebird، IBM Db2، MariaDB ،Microsoft SQL Server، MS Access، Oracle، Postgres ،‌ SAP HANA و SQLite اشاره نمود.

2. پایگاه داده­ های کلید-مقدار (Key-Value Database)

پایگاه‌های داده های کلید-مقدار یا همان NoSQL، همانطور که از نام آن پیداست، داده‌ها را در جداول پخش نمی‌کنند در نتیجه داده‌های تکراری در داخل یا بین جدول وجود ندارند. فناوری های پایگاه دادهNoSQL معمولاً رویکردی مبتنی بر سند (document) برای ذخیره سازی داده ها دارند. اسناد معمولاً با فرمت JSON در یک واحد سازماندهی‌شده به نام مجموعه (collection) ذخیره می شوند. در حالی که سازماندهی اطلاعات در یک سند طبق یک ساختار استاندارد صورت می‌گیرد، هر سند در مجموعه را می توان به هر نحوی قرار داد. برای مثال، یک سند می‌تواند حاوی اطلاعات first_nameو last_name باشد، در حالی که سند دیگر می‌تواند حاوی اطلاعات first_name، last_name و email باشد. سند سوم می تواند حاوی اطلاعات نام محصول و مقدار باشد.

مزیت پایگاه های داده NoSQL این است که آنها تطبیق پذیری بسیاری را ارائه می دهند و اشکال آنها این است که تمایل دارند مقدار زیادی از اطلاعات اضافی را جمع آوری کنند. در نتیجه، یکپارچگی (Integrity) داده‌ها می‌تواند به خطر بیفتد و ارتباط دادن داده ها بین مجموعه ها می‌تواند دشوار باشد.

از پایگاه‌های داده‌ای NoSQL هم می‌توان از Cassandra، Couchbase،Elasticsearch ، InfluxDB، MongoDB، Redisو Riakنام برد.

3. پایگاه داده ­های نموداری (Graph Databases)

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

محبوبیت پایگاه‌های اطلاعاتی گراف، به‌ویژه در میان سایت‌های رسانه‌های اجتماعی (Social Media) که نه تنها در مورد موجودیت‌هایی که از آنها استفاده می‌کنند، بلکه به رابطه بین موجودیت‌ها نیز نیاز دارند، در حال افزایش است. به عنوان مثال، یک کاربر در فیس بوک می تواند دوست کاربر دیگری و عضو یک گروه باشد.

از پایگاه‌های داده‌ی نموداری هم AgangoDB، Neo4J و OrientedDB قابل اشاره هستند.

مقایسه پایگاه ­داده­ های رابطه ­ای، کلید-مقدار و نموداری

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

· در پایگاه داده های کلید-مقدار ساختار و چارچوب اطلاعات بقدری سیال است که گاهی می­توان گفت که هیچ ساختاری ندارند. بی­ ساختاری به همان میزان که می­ تواند مزیت محسوب شود ممکن است در نهایت موجب از بین رفتن ثبات (Consistency) در داده ­ها شود. شاید برای ما صحت و یکپارچکی لحظه­ای و کلی داده­ ها مهم نباشد اما مطمئنا بدنبال ثبات نهایی (Eventual Consistency) خواهیم بود. این پایگاه داده ­ها نیز علی­رغم عملکرد مناسب در تراکنشهای کوچک در بحث تحلیل عمیق دچار مشکلات فراوان عملکردی سرعت و دقت می­باشند.

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

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

چگونه پیاده­ سازی کنیم
از پایگاه‌های داده‌ی رابطه‌ای پرکاربرد که دارای پشتیبانی بهتری می‌باشند می‌توان به پایگاه داده‌ی SQL Sever شرکت مایکروسات و Oracle اشاره نمود. البته در صورتی که بحث‌های کپی ­رایت و هزینه‌ مجوزهای این پایگاه‌ داده ­ها مهم و غیرقابل چشم پوشی باشد، پایگاه داده‌ی Postgres و در رتبه‌ی بعدی MySQL، پیشنهاد داده می‌شود.