این سوال به دو بخش قابل تفکیک است.
1. چه مبنایی برای شکستن یک محصول به چند مولفه ها وجود دارد؟
بنده کاربردی ترین دستورالعملی که در این زمینه مشاهده کردم مربوط به رویکرد Domain Driven Design است. پیشنهاد می کنم این مقاله را مطالعه بفرمایید.
2. با چه تکنیکی یک مولفه به اطلاعات یک مولفه دیگری دست پیدا کند؟
طبیعتاً بهتر است وابستگی دو مولفه هر چه کمتر باشد و یکپارچه سازی در سطح سرویس و نه سطح داده صورت بگیرد. مخصوصاً اگر یکپارچه سازی دو مولفه از طریق تبادل پیامهای ناهمزمان با واسطه یک میان افزار تبادل پیام مثل ActiveMQ یا RabbitMQ یا Kafka صورت بگیرد وابستگی دو مولفه حداقل خواهد شد.
بهتر است API ارتباط دو مولفه به گونه ای طراحی شود که برای مولفه های دیگر نیز قابل استفاده باشد.
در برخی موارد نیازمند یکپارچه سازی دو مولفه در سطح داده هستیم. در این صورت پیشنهاد می شود موارد زیر مد نظر قرار بگیرد.
-
نباید برای سادگی همه مولفه ها را در یک اسکیما قرار بدهید. در بلند مدت از این کار پشیمان خواهید شد چون ارتباط یک مولفه با جداول مولفه دیگر مدیریت پذیر نیست و تفکیک آنها در آینده بسیار دشوار می شود. در نتیجه تغییر مدل داده بسیار پر ریسک و لخت خواهد شد.
-
می توانید جداول دو مولفه را در دو اسکیمای مختلف روی یک پایگاه داده نگهداری کنید. برای دسترسی مولفه دوم به اطلاعات مولفه اول می توانید چند View با فیلدهای اطلاعاتی حداقلی در اسکیمای مولفه دوم بسازید.
-
در صورتی که نمی توانید دو مولفه را به یک پایگاه داده متصل کنید، از تکنیکهای replication یا Master Data Management برای انتقال اطلاعات از مالک داده به مصرف کنندگان استفاده کنید.
-
حتماً تنها یکی از مولفه ها باید روی اطلاعات مشترک اجازه نوشتن داشته باشد و بقیه دسترسی فقط خواندنی دارند. برای تغییر داده از سرویس استفاده کنید.
-
اگر یکپارچه سازی در سطح داده برای مقاصدی همچون گزارشگیری و نظارت است احتمالاً با ایجاد یک زیرساخت BI و انتقال کلیه اطلاعات به آن با ابزارهای ETL می توانید گزارشات تجمیعی را ایجاد کنید.
