خیلی خوشحالم که بعد از مدتها (و بعد از انبوه تاپیکهای درخواست انجام پروژه دانشجویی و ...) یک بحث خوب تو فروم شروع شده و امیدوارم برای همه ما قابل استفاده و مفید باشه.
در مورد کلاسهایEntity نظرتون درسته، در مورد کلاس کنترل علاوه بر مواردی که برشمردید، وظیفه انتقال اطلاعات به/از کلاسهای Bondry و Entity به دیگر کلاسها و هماهنگی میان عملیات آنها هم معمولا بعهده کلاسهای کنترل است (وظایف کلاس های کنترل محدود به بررسی یک سری شرایط و اعمال محدودیتها نمیشوند).
در مورد کلاس Boundry احتیاج به توضیح است : اگر سیستم مالی بصورت یک نرم افزار خارج از سیستم ثبت نام باشه، بنابراین باید به صورت یک Actor مدل بشه و برای ارتباط با اون باید از کلاس Boundry استفاده کرد. بنابراین کلاس Boundry در اینجا عملیات مالی را انجام نمیدهد، بلکه فقط دادههای مالی مرتبط با سیستم مالی را به آن ارسال میکند و احتمالا دادههایی را نیز از سیستم مالی دریافت میکند( که البته گمان میکنم منظور شما نیز تا حدود زیادی همین بوده است).
خوب است اشاره کنم که در این مورد یک کلاس Boundry دیگر برای ارتباط با Actor ی که عملیات ثبت نام را انجام میدهد (دانشجو یا کارمند آموزش) لازم است که در واقع فرم ثبت نام را مدل میکند.
اگه دقت کنید در اینجا ما دادهها را در کلاس Entity قرار میدهیم، عملیات بر روی آنها را در کلاس Control و نمایش آنها را در Boundry. در صورتی که Encacsulation به ما رهنمود میدهد که داده و همه اعمالی که بر روی آن اعمال میشود را در یک کلاس قرار دهیم. البته بعضی هم در برابر این نقد، میگویند که سطح تجرید در این مورد بالا تر از کلاس است و ... خلاصه بحث همچنان باقی است.
در مورد کلاس Boundry که مثال زدم (فرم ثبت نام). در مورد کلاس کنترل هم میتوانید یک کلاس کنترل اصلی در نظر بگیرید (Registeration) که وظیفه اجرای کل ثبت نام (با همکاری بقیه) را دارد : اطلاعات فرم ثبت نام را به کلاس کنترل زمان میدهد، اطلاعات را از Entity ها میگیرد، اطلاعات مالی را به کلاس Boundry مرتبط با سیستم مالی میدهد و نتیجه را میگیرد .. تا ثبت نام پایان پذیرد.