پیچیدگی میتواند پشت ساختار پنهان شود
اضافه کردن پوشه، interface، service و abstraction میتواند یک codebase را معماریشده نشان دهد، بدون اینکه تغییر آن واقعاً آسانتر شود. ساختار زمانی کمک میکند که مرزهای مفیدی پیرامون مسئولیتها ایجاد کند.
برای من معماری باید به یک سؤال ساده پاسخ دهد: وقتی بخشی از محصول تغییر میکند، چه مقدار نرمافزار نامرتبط هم مجبور به تغییر میشود؟
از مسئولیت و مالکیت شروع کن
یک مرز قوی معمولاً دلیل منسجم برای تغییر، قرارداد صریح و مالک مشخص دارد. این مرز میتواند داخل یک Modular Monolith یا میان چند سرویس جدا وجود داشته باشد. توپولوژی استقرار نتیجه معماری است، نه تعریف ماژولاریتی خوب.
کوچکترین ساختاری را انتخاب کن که از تغییر محافظت کند
معماری مناسب اغلب سادهترین ساختاری است که از مرزهای مهم محافظت میکند. اگر یک ماژول بتواند بدون درد عملیاتی یا سازمانی در یک واحد قابل استقرار باقی بماند، شاید هنوز جدا کردن آن به یک سرویس شبکهای ارزشی نداشته باشد.
سیستمی دارید که این بدهبستان در آن مهم است؟
شروع گفتوگو ←