DDD-дегі bounded context: домендер мен интеграцияларды қалай бөлу керек

Неге домендерді бөліп, шекара белгілеу керек

Кез келген корпоративтік жүйе көбіне «модульдері бар бір монолит» ретінде басталады. Алғашында ыңғайлы: бір репозиторий, бір база, ортақ анықтамалар. Бірақ функционал өскен сайын модульдер бірдей сущностар мен ережелер үшін «тартыса» бастайды. Бір жерде өзгеріс күтпеген жерден басқа жерді бұзады.

Бастапқы симптомдар бірдей: бірнеше команда бірдей кестелерді «қауіпсіздік үшін» түзетеді; ортақ терминология тарқайды (сол "клиент" немесе "заказ" әртүрлі мағынада); жалпы кезектер мен топиктерге бәрі қалағанын жазады да, кейін бәрі бөтен форматтарды талдап шығуға мәжбүр болады; "ортақ" утилиталар жүйенің жартысын тартады. Релиздер сирек болады, себебі бәрін бірден тестілеу керек.

Командалар көбейген сайын келісім құны дамудан жылдам өседі. Архитектура талқылау клубына айналады: бір функция қосу үшін бірнеше иемен келісу және ондай тәуелділіктерді қайта қарау керек.

Міне осы жерде DDD-дегі bounded context көмектеседі: айқын шекаралар, ішінде модель мен терминология келісілген, сыртқа тек келісілген интерфейстер шығады. Шекара «сән үшін» емес — өзгерістер локальды және болжамды болуы үшін қажет.

DDD негізгі ұғымдары — артық теориясыз

DDD — мағынаны қалай келісуге болатынын көрсететін тәсіл. Команда жүйені бизнес қатысушылары қалай сөйлейтініндей сипаттайды және сол тілден модель жасайды: сущностар, ережелер, статустар, сценарийлер. Модель мен сөйлесу тілі сәйкес келсе, талаптардағы және аналитик, дамытушы, пайдаланушы арасындағы «аудармадағы» қателер азаяды.

Домен — жүйе үшін маңызды бизнес аймағы (мысалы, сатып алу, есеп, техподдержка). Домен ішінде әдетте поддомендер болады: ядро (бәсекелік артықшылық беретін бөлік) және типтік рутина, оны қарапайымрақ жасауға болады.

Модель — диаграмма немесе дерекқор емес. Бұл — ұғымдар мен ережелер жинағы: не «заявка», қашан ол «одобрена», кім соманы өзгерте алады, қандай статустар қабылданады. Модель кодада және команданың сөйлеуінде өмір сүреді.

Контекст — сөздердің нақты мағынасы бар және бір модель жұмыс істейтін жер. Контекст шекарасы жауапкершілікке қарай өтеді: кім ережелерге ие, кім деректерге жауапты, өзгерістер туралы шешімді кім қабылдайды.

Сол бір сөйлем әр түрлі жерлерде әртүрлі мағынада болуы мүмкін. Сатылым бөлімінде "клиент" — компания, бухгалтерияда — төлеуші, қолдау көрсетуде — инциденттері бар пайдаланушы. Барлығына бірдей анықтама жасау модельді компромисске айналдырады және өзгерістер ауыр болады.

DDD әсіресе бірнеше команда мен интеграциясы бар корпоративтік жүйелерде пайдалы: модульдер параллель дамиды, талаптар жиі өзгереді, келісулер көп, терминдер әртүрлі қолданылады, интеграция бірнеше жүйелер арқылы жүреді (ERP, CRM, сервис-деск).

Жүйелік интеграция жобаларында осындай мағыналар туралы келісімдер көбіне фреймворк таңдауынан да маңызды: олар өсу кезінде жүйені хаостан қорғайды.

Bounded context деген не және оның шекарасын қалай түсінуге болады

Bounded context — жүйеде сөздер мен ережелер бір мағынада қолданылатын жауапкершіліктің анық аймағы. Ішінде модель өз-өзін қайшылыққа салмайды: «Заказ» дегенде команда оның дәл қандай статустары барын біледі.

Жақсы контекст әдетте үш нәрседен танылады: айқын мақсаты, жауапты иелері және тұрақты тіл (терминдер экраннан экранға өзгермейді).

Шекарада негізгі сущностар, бизнес-ережелер және осы ережелерге қажет деректер, сондай-ақ контекст басқа жүйелерге қызмет көрсететін интерфейстер (API, командалар, сценарийлер) болуы тиіс. Интеграцияға қатысты келісімдерді шекараға қою жақсы: контракттар, оқиғалар, форматтар және үйлесімділік ережелері. Солайша ішкі өзгерістер көршілерді сирек бұзады.

Шекараның «ені» тексерудің қарапайым ережесі:

• Тым кең шекара: бір жерде көптеген қайшы терминдер, «қалай дұрыс» туралы жиі даулар, өте әр түрлі мақсаттар бір жерде.
• Тым тар шекара: әр әрекет үшін 3–4 модульге жүгіру қажет, қарапайым операциялар үшін көп интеграция.

Мысал: сатып алуда «Поставщик» — келісімшарттары мен жеткізу шарттары бар контрагент, ал бухгалтерияда «Поставщик» — төлемдер мен есепке алу жазбасы. Барлығына бір «Поставщик» жасасаңыз, модель тез компромисске айналып, кедергі болады.

Жауапкершілікті бекіту үшін алдын ала контекст иесін белгілеңіз: кім терминдерді, ережелер мен модель өзгерістерін мақұлдайды және көрші командалармен дауда кім шешім қабылдайды.

Домендерді бөліп алу: корпорацияға арналған практикалық тәсіл

Бастамай тұрып модульдерден немесе оргструктурадан бастамаңыз — бизнес мақсатынан бастаңыз. Жүйе күнделікті қандай шешімдер қабылдауға көмектесуі керек: не мақұлдауға болады, не мақұлданбайды, қай жерде келісім қажет, қай жерде жылдамдық маңызды, ал қай жерде дәлдік пен аудит маңызды.

Келесі қадам — 5–10 негізгі процесті және рөлдерді жинау, бірақ экрандар мен батырмаларға түспеңіз. Пайдасы бар тәсіл — жұмыс ағынын прост тілмен сипаттау: кім бастайды, кім тексереді, кім жауапты, дұрыс нәтиже қандай.

Көбіне шекаралар ережелер мен сөздік өзгеретін жерден пайда болады. Бірдей сөздер әр команда үшін әртүрлі мағынаны білдірсе — сіз әр түрлі bounded context-те тұрсыз. Мысалы, сатып алудағы «заказ» — сатып алу өтініші, ал логистикада — нақты жеткізу күндері мен статустары бар партия.

Деректерге қатысты талас болмас үшін деректердің шындық көзі кемінде алдын ала белгіленуі керек. Корпорацияларда бір контекст контрагенттер справочнигін, басқа бағаларды, үшіншісі қалдықтарды иеленуі мүмкін. Мақсат — бір «идеал объектіні» жасамау, кім жасайды, кім оқиды және не ресми дереккөз екенін келісу.

Бастапқы бөлініс үшін қарапайым шкала көмектеседі:

• Core: компанияға айырмашылық беретін және ережелері жиі өзгеретін бөлік.
• Supporting: маңызды, бірақ ерекше емес, қарапайым жасауға болатын бөлік.
• Generic: авторизация, хабарландырулар, есептер сияқты типтік функциялар.

Мысал: интеграторлық жобада core — келісімшарттар мен сатып алу лимиттерін басқару, supporting — жеткізілім есепі мен кепілдіктер, generic — пайдаланушылар каталогы және рөлдер. Осындай көзқарас қай жерде күшті домендік модель ұстау керектігін және қай жерде күрделендірмеу керектігін көрсетеді.

Контекст картасын қалай құру және келісімдерді рәсімдеу

Контекст картасы — қай модель қай жерде аяқталатынын және қай жерде басталатынын барлығына бірдей көрсету үшін керек. Құралдардан емес, тіл мен жауапкершіліктен бастаңыз.

Терминдерді экрандардан, есептерден, хаттардан, келісімшарттардан, тикеттерден жинаңыз. Қай жерде сөз қолданылатынын және оның қандай мағына беретінін жанында жазыңыз. Бірдей "клиент" сатылымда және қолдауда әртүрлі болса — оны бірден көрсеткен жөн.

Әр негізгі термин үшін деректер иесін анықтаңыз. Иесі кестені ұстайтын емес, мағынаға, өзгерістер ережелеріне және сапаға жауапты адам. Мысалы, "Заказ статусы" бір иесі болуы керек, тіпті оны бес модуль оқыса да.

Содан кейін бір бетке 5–8 контекст саласыңыз: әрқайсысының қысқа мақсаты (бір сөйлем) және шекарасы. Мұнда толық бөлініс емес, маңыздысы — кез келген уақытта «бұл біздің емес» және «мұнда біздің басталады» деп айта алу.

Әр контексттің кіріс-шығыстарын сипаттаңыз: командалар, сұраулар, оқиғалар, файлдар. Келісімдердің шашылмауы үшін минимумды бекітіңіз:

• терминдер глоссарийі және әр контекстегі мәні;
• деректер иелері және өзгерістер ережелері;
• интерфейстер (не береміз және не күтеміз);
• интеграция түрі (API, оқиғалар, экспорттар);
• контракттардың версийлері және үйлесімділік ережелері.

Қорытынды қадам — командалармен және релиз жоспары бойынша шекараны келісу. Кім контрактты қолдайтынын, өзгерістер көршіні тоқтатпай қалай шығатынын тексеріңіз және мәндер қақтығыс болғанда не істеу керектігін анықтаңыз (маппинг немесе бөлек қорғау қабаты арқылы).

Модульдер арасындағы интеграция ережелері: алдын ала не шешу керек

Модульдер арасындағы интеграциялар масштабтауда технологиядан гөрі күтулердің анық еместігінен жиі бұзылады: кім кімге не беруі керек, қашан, қандай форматта және ақау болғанда не істеу керек. Шекаралар көмектеседі, бірақ алмасу ережелері болмаған соң деректер мен жауапкершілік командалар арасында "ақиды".

API синхронды жауап қажет болғанда қолайлы: лимитті тексеру, статус алу, бағаны есептеу. Алдын ала келісуді қажет етеді: қандай операциялар критикалық, қандай таймауттар қабылданады және қандай қателер қалыпты (мысалы, дерек жоқ па әлде сервис қолжетімсіз бе).

Оқиғалар моделі — өзгерістер жүйеге байланыссыз таратылуы керек болғанда жақсы: "Заявка мақұлданды", "Счет төленді", "Тауар қабылданды". Бұл байланысты азайтады, бірақ тәртіпті талап етеді: оқиға түсінікті, тұрақты және ішкі модельді түгел жіберіп алмауы тиіс.

Пакеттік алмасу онлайн сұраулардың қажеті жоқ жерлерде жарайды: түнгі синхрондау, справочниктерді жүктеу, есептерді экспорттау. Кемшілігі — деректер сәл ескі болады және қателер кеш ашылады.

Синхронды не асинхронды таңдау үшін критерийлер жеткілікті: пайдаланушыға дереу жауап керек пе — API; кейін өңдеуге болады — оқиғалар; сағаттармен кешіктіруге болады — пакет; сыртқы модуль қателігі сізді блоктаудың қажеті жоқ — асинхронды; шындық көзі жылдамдықтан маңыздырақ болса — синхронды.

Жеке тақырып — контракт. Кейбір нәрселерді кейін өзгерту ауыр: версийлеу (ескі версия қанша өмір сүреді), кері үйлесімділік, қателер ережелері (кодтар, мәтіндер, рекTry, дедупликация), деректер схемасы (міндетті өрістер, күн мен сомалар форматтары), өзгерістерге жауапты кім (кім хабар береді және қалай тестіленеді).

Мысал: "Закупки" модулі «Заказ подтвержден» оқиғасын жібереді, ал "Учет" бөлшектерді тікелей шақырмай, тек есептер үшін қажет деректерді сақтайды. Солай "Закупки" ішіндегі өзгерістер "Учет"-ті сирек бұзады.

Модельдерді араластырмау: контракттар, маппинг және антикоррупциялық қабат

Екі bounded context өздерінің сущностарын тікелей алмастырғанда модель тез "ластанады". Нәтижесінде әр релиз көршілерді бұзады, командалар өрістердің мағынасы туралы дауласады. Қарапайым қағида көмектеседi: интеграция көбіне аударманы талап етеді, тіпті деректер ұқсас болса да.

Аударма керек, өйткені бір сөз әртүрлі мағына беруі мүмкін. Сатылымда "клиент" адам болуы мүмкін, ал биллингте — келісімшартпен төлеуші. Бір объектіні басқаға сүйреу арқылы сіз оның шектеулерін де ендіресіз.

Антикоррупциялық қабат (ACL)

ACL тұтынушы жағында орналасады: сыртқы хабарды қабылдап, тексеріп, өз терминдеріңізге аударады да кейін ғана сақтайды.

ACL-да әдетте өрістер мен форматтарды маппингтеу (кодтар, күндер, валюта), мәннің логикасын тексеру (мысалы, сыртқыда «жабылған» өтініш сізде «төлеп қоюға дайын» деп саналмауы мүмкін), өз справочникаларын бөлу және сәйкессіздіктерді өңдеу (мән белгісіз, өріс жоқ, ереже қайшылық табылды) жүзеге асады.

Деректер контракттары: аздау, бірақ нақтылырақ

Контракт минималды және түсінікті болғаны дұрыс: тек алушыға шынымен қажет нәрсе және нақты мәндер. "Бүтін өтінішті жібереміз" деудің орнына — "факт пен негізгі атрибуттарды жібереміз" деген ыңғайлы.

Жақсы тәжірибе — шеткі статустар мен справочниктерді импорттамау. Сыртқы статусты сигнал ретінде қабылдап, оны өзіңізге аударыңыз. Мысалы, сыртқы APPROVED сізде «Тапсырыс беруге рұқсат» немесе кейде «Қосымша тексеруді талап етеді» болуы мүмкін, егер лимиттер мен рөлдер сәйкес келмесе.

Терминдер айырмашылығы болса, оны контракт пен маппингіде шешіңіз, барлығына ортақ «бір ғана справочник» арқылы емес. Осылай шекаралар таза қалады және даму мәңгілік қайта жазуға айналмайды.

Оқиғалар, процестер және контексттер арасындағы деректер келісімі

Контексттер арасындағы оқиғалар командаларға бөтен кестелерді сүйруге және көрші модульдің ішкі логикасына тәуелді болмауға көмектеседі. Бірақ әрбір өзгерісті оқиғаға айналдыру қажет емес.

Сыртқа ғаламдық мағынасы бар және бизнестің басқа бөліктеріне түсінікті нәрсені жіберіңіз: "Заказ расланды", "Счет шығарылды", "Тауар қабылданды". Ал "пайдаланушы батырманы басты" немесе "статус 3-тен 4-ке өзгерді" сияқты ішкі детальдарды іште қалдырған жөн — олар жиі өзгеріп, интеграцияларды бұзады.

Бір бизнес-процесс бірнеше контекст арқылы өтсе, кім оны басқаратыны сұрағы туындайды. Егер қадамдар тәуелсіз орындалса, оқиғаға реакция жеткілікті. Қатаң тәртіп, таймауттар, откат немесе қолмен шешім қажет болса — сагасыз істемейсіз. Сага — процесс дирижері: 1-қадам аяқталғанын бақылайды, 2-қадамды бастайды және ақау болғанда компенсация жасайды (мысалы, резервті босату).

Идемпотенттік қажет, өйткені оқиғалар екі рет келуі мүмкін: қайталау жеткізілімдері, ретрайлер немесе желі ақаулары себебінен. Қабылдаушы қайталануды қауіпсіз өңдей білуі керек. Бұл әдетте оқиғада тұрақты идентификатор бар және өңдеуші өңделген фактіні сақтап, қосарлануды жасамайды дегенді білдіреді (екі шот ашпайды, ақшаны екі рет алып тастамайды).

Ақырғы келісімді бизнес пен QA-пен алдын ала талқылау керек. Оқиғадан кейін басқа контекстте деректер бірден емес, секундтар немесе минуттар ішінде жаңарады. Бұл қалыпты — маңыздысы ережелер: қай жерде «өңделіп жатыр» көрсетіледі, қандай әрекеттер растау болмағанша тыйым салынады, қандай кешігулер қабылданады.

Оқиғалар әңгімеге айналмасын десеңіз, әр жарияланатын публичті оқиғаны контракт ретінде құжаттаңыз: атауы мен бизнес мағынасы, қашан жарияланады және кім дереккөзі, өрістер мен олардың мәндері (міндетті және опционал), жеткізу мен тәртіпке қатысты күтулер (қысқаша: қосарлану және кешігу мүмкін), версийлеу ережелері (жаңа өрісті қалай қосамыз, тұтынушыларды бұзбай).

Масштабтау дамуды неге бұзады — жиі кездесетін қателіктер

Мәселелер көбіне шекара салу кезеңінде емес, команда өскенде және әр модуль деректер мен мағынаны өзінше өзгертуді бастаған кезде шығады. Тіпті bounded context келісілген болса да, модель иелігі мен интеграция қателері өзгерістерді ақаулар тізбегі етпей қоймайды.

Қате 1: шекараны жауапкершілікке емес, кестелерге қарай сызады

Көбіне модульді оның өз схемасы бар деп бөледі. Бірақ жауапкершілік анықталмаған: «статус» немесе «клиент» дегенді кім шешеді? Нәтижесінде домендік логика сервистер мен триггерлерге тарап кетеді.

Қате 2: барлығына бір модель, себебі тез

Бір «канондық» объект ыңғайлы көрінеді: аз маппинг, аз код. Бірақ кейін әр термин әр команда үшін басқа мағынаға ие болады. Сатып алу мен бухгалтериядағы "заказ" әр түрлі ережелерге бай, және бір модель бәріне кедергі болады.

Басқа типтік қателер:

• иесі жоқ ортақ справочниктер (өзгерістер «сұрау бойынша» және үйлесімділіксіз);
• бірнеше контекст арқылы өтетін сквозной транзакциялар (кез келген кідіріс бәрін бөгейді);
• бір контекстің кестесіне немесе ішкі әдістеріне тікелей қолжетімділік арқылы интеграция (ішкі іске асу детальдарына тәуелділік);
• контракттарды версийлеудің болмауы (бір өріс тұтынушыларды бұзады);
• «деректер» пен «мағынаны» араластыру (бөтен өрістерді әкеліп, олардың интерпретациясын түсінбей);

Микро-мысал: сатып алу командасы жаңа статус — "Частично поставлено" қосты, ал есеп командасы статусқа проводкалар триггері ретінде қарайды. Егер контракт версийленбей және маппинг болмаса, есеп артық немесе кем операция жасай бастайды.

Зрелдіктің жақсы белгісі: әр справочник пен оқиғада иесі бар, контракттар ережемен өзгереді және интеграциялар жария шекаралар арқылы өтеді, "жылдамырақ" деген желеумен тікелей қолжетімділік арқылы емес.

Команда өсуі мен бөлінуден бұрынғы қысқа чек-лист

Модульдерді бөліп, әрқайсын бөлек командаға бергенге дейін қысқаша тексеруден өтіңіз. Бұл шекаралардың көзбен салынбағанын және релиздерден кейін хаосқа ұрынбайтынын тексеруге көмектеседі.

Ең алдымен: әр bounded context-тің айқын мақсаты мен иесі болуы тиіс. Егер бір сөйлеммен контексттің неге жауапты екенін және оның моделіне кім шешім қабылдайтынын түсіндіру мүмкін болмаса — шекара әлі дайын емес.

Негізгі нәрселерді тексеріңіз:

• деректер шекарасы: не осында сақталады, не сырттан тек оқылады;
• интеграциялар тізімі және олардың түрі (API, оқиғалар, пакет);
• контракттардың версийленуі және үйлесімділік ережесі;
• справочниктер бойынша саясат: бір шындық көзі ме әлде көшірмелер бе, және сапаға кім жауапты;
• сквозной процестер үшін — қадамдарды кім оркестрлейді (процесс бір контекстте ме әлде бөлек модульде ме).

Кейін модельдерді араластырмаудың қауіпін тексеріңіз. Егер модуль A модуль B-тің кестелеріне тікелей жазады немесе оның ішкі өрістерін «қайталайды» болса, бөліну ауыр өтеді. Алдын ала келісіңіз: тек ашық контракттар және анық маппинг арқылы.

Дайындық критерийі қарапайым: контекст тәуелсіз шығарыла және өзгертіле алуы керек. Мысалы, есеп командасы ішкі «Статус» өрісінің өзгеруі үшін сатып алу командасынан шұғыл патч сұрамай ережелерін жаңарта алуы тиіс. Егер олай болмай жатса — шекаралар мен интеграцияларды қайта қараңыз.

Мысал: сатып алу мен есепті ауыртпай қалай бөлуге болады

Корпорацияны қарастырыңыз: сатып алу, қойма, қаржы және ITSM бөлімдері бар. Команда өзгерістерді жеделдеткісі келеді, ал қазір бәрі бір базада, кез келген жаңа есеп жүйенің жартысын бұзады. Мұнда DDD-дегі bounded context жауапкершілікті осылайша бөледі, команда өскенде келісулерге ұрындырмай.

Старттық контексттер жиі былай көрінеді:

• Заказы: өтініштер, мақұлдаулар, жеткізушіні таңдау, заказ өмірлік циклы статустары.
• Поставки: отгрузка, қабылдау, айырмашылықтар, партиялар, құжаттар.
• Бюджеттер: лимиттер, мақалалар, резервтеу, фактілер, бақылау.
• Активтер: есеп бірліктері, инвентарлық нөмірлер, қозғалыстар, списания.

Болғанша ауыртатын жерлер — бірдей сөздердің әртүрлі мағынасы. "Заказ статусы" сатып алуда — «на согласовании» немесе «поставщик таңдалды», ал жеткізілімде статус логистика туралы. "Есеп бірлігі" активтерде — инвентар номері, қоймада — дана, қорап немесе партия. "Приемка" Поставкиде — сан мен сапаны растау, ал Қаржылар үшін — міндеттікті мойындау және төлем жасау негізі.

Интеграцияларды алдын ала оқиғалар мен сұрауларға бөліңіз. Мысалы, Поставки «Тауар қабылданды» оқиғасын жариялайды (заказ нөмірі, позициялар, саны, күндері), Бюджеттер мен Қаржы жазбалар жаңартады. Сонымен бірге Заказы әр батырмаға Бюджеттерге сұрау жібермейді: қарапайым API бар — "лимитті тексеру" және "соманы резервтеу" нақты контрактпен.

Монолитке қайтып оралмау үшін ереже қойыңыз: жалпы кестелер мен тікелей SQL арқылы интеграция болмайды. Әр контекст өз базасына және моделіне ие, ал шекарада алмасу контракттармен (оқиғалар мен API) және анық маппингпен жүреді.

Келесі қадамдар: пилот, инфрақұрылым және өзгерістерді қолдау

Барлығын бірден бөлуден гөрі пилоттан бастаңыз. Көбіне 1–2 контекст жеткілікті: қай жерде қақтығыстар жиі, релиздер күрделі, қолмен келісімдер көп. Жақсы кандидат — бизнес үшін айқын құндылығы бар және сыртқы тәуелділігі аз контекст.

Пилотты дауласпауы үшін алдын ала қалай жақсарғанын өлшейтін 3–4 метрика мен әр 2–4 аптада ретродан өтуге келісіңіз: пилот модульдеріндегі өзгерістен релизке дейінгі уақыт (lead time), талаптар қақтығыстары мен тапсырма қайта жіберулер саны, релизтен кейінгі инциденттер және қалпына келтіру уақыты, «ережені айналып өту» саны (қолмен синхрондау, басқа базада тікелей сұраулар).

Содан кейін минималды инфрақұрылым мен ережелер жиынтығын дайындаңыз, шекаралардың тарқамауы үшін: контракттарды сипаттаудың бір әдісі, бөлек ортақ тесті ортасы, мониторинг. Бастапқыда API/оқиғалар бойынша құжаттама мен иелері, интеграцияның үйлесімділігін тексеруге тесттік орталар, негізгі ағындарға лог/метрикалар/алармдар, қорғаныс көшірмелер мен қалпына келтіру жоспары жеткілікті.

Пилот нәтиже көрсеткеннен кейін жиі «темір» пен сервис негізі керек болады: сервистер мен кезектерге серверлер, сақтау орындары, командаларға жұмыс орындары, 24/7 қолдау. Мұндай мәселер бойынша жүйелік интегратор пайдалы: ол толық тізбекті жабады. Мысалы, GSE.kz (gse.kz) Қазақстанда өндіруші және интегратор ретінде серверлер мен жұмыс станцияларын жеткізіп, енгізу мен қолдауды өз мойнына алады.

Бұл кезеңдегі басты ереже: контекст картасын тек пилот бірнеше релизден және инциденттен кейін табыс көрсеткен соң кеңейтіңіз. Тұрақты түрде "барлығына ортақ модельге" қайта оралмау үшін пилоттың шекараларын тексеріңіз.