Ubiquitous language — Domain-Driven Designda loyiha ishtirokchilari domenni tasvirlash uchun kelishib ishlatadigan umumiy va aniq tildir. Undagi atamalar biznes suhbatida, talablar hujjatida, diagrammada, testlarda va dastur kodida bir xil ma’noni anglatadi. Maqsad texnik jamoa bilan domen mutaxassislari orasidagi tarjima xatolarini kamaytirishdir.
Tilning shakllanishi
Ubiquitous language tayyor lug‘atni bir marta yozish bilan yaratilmaydi. Dasturchilar va domen mutaxassislari real jarayonlarni muhokama qiladi, noaniq so‘zlarni aniqlaydi va qarama-qarshi ma’nolarni ajratadi. Model o‘zgargan sari til ham qayta ko‘riladi. Yangi atama faqat qulay kod nomi bo‘lgani uchun emas, domen hodisasini aniq ifodalagani uchun qabul qilinadi.
Masalan, savdo tizimida order, reservation va shipment alohida holatlardir. Ularni umumiy “record” yoki “item” deb atash muhim qoidalarni yashiradi. Aksincha, biznesda bir xil jarayon uchun “buyurtma” va “so‘rov” aralash ishlatilsa, jamoa ularning aynan bir tushunchami yoki boshqa bosqichlarmi ekanini aniqlaydi.
Koddagi aks etishi
Kelishilgan nomlar class, method, event va modul nomlarida ko‘rinadi. CancelOrder amali domen suhbatida ham “buyurtmani bekor qilish” deb yuritilsa, kodni o‘qigan mutaxassis niyatni tezroq tushunadi. calculateFlag kabi texnik va noaniq nom o‘rniga biznes qoidasini ifodalovchi determineEligibility nomi modelni ravshanlashtirishi mumkin.
Bu qoida har bir texnik elementni biznes tiliga aylantirish degani emas. Database connection pool yoki HTTP middleware texnik infratuzilma atamalaridir. Ubiquitous language asosan domen modelining chegarasida ishlaydi. Texnik qatlam bilan domen qatlamini ajratish biznes so‘zlarining framework tafsilotlari bilan aralashib ketishini kamaytiradi.
Bounded Context bilan bog‘liqligi
Bitta so‘z katta tashkilotning turli qismlarida har xil ma’noga ega bo‘lishi mumkin. “Customer” savdoda xaridor, qo‘llab-quvvatlashda murojaat egasi, billingda esa yuridik to‘lovchi bo‘lishi ehtimol. DDD barcha bo‘limni bitta sun’iy ta’rifga majburlash o‘rniga atamani bounded context ichida izchil saqlaydi.
Kontekstlar tutashganda tarjima aniq adapter yoki mapping orqali bajariladi. Context map qaysi model qayerda amal qilishini ko‘rsatadi. Bir kontekst obyektini ikkinchisiga bevosita ko‘chirib, nomi bir xil ekaniga tayanish semantik xatoga olib kelishi mumkin.
Spetsifikatsiya va testlar
BDD scenario va acceptance testlar ubiquitous language uchun amaliy tekshiruv vazifasini bajaradi. Given–When–Then qadamlarida domen atamalari ishlatilsa, mahsulot egasi talabni o‘qib tasdiqlay oladi. Test qadamida UI selektori yoki jadval nomi ustun bo‘lsa, spetsifikatsiya texnik implementatsiyaga bog‘lanib qoladi.
Misollar atamaning chegarasini ko‘rsatadi. “Faol obuna” tushunchasi to‘lov qilinganini, muddati tugamaganini va bekor qilinmaganini anglatadimi — buni konkret senariylar aniqlashtiradi. Lug‘at qisqa ta’rif beradi, bajariladigan misol esa qoida qanday ishlashini ko‘rsatadi.
Hujjatlash va boshqarish
Jamoa asosiy atamalar, sinonimlardan voz kechish sababi va kontekst chegarasini glossaryda saqlashi mumkin. Glossary yakuniy haqiqatning yagona manbasi emas; kod, test va suhbatdagi nomlar bilan mos bo‘lishi kerak. Eski termin almashtirilsa, faqat hujjat emas, API, event va ma’lumot modeli migratsiyasi ham rejalashtiriladi.
Tilning sifati meetingdagi so‘zlarni mexanik standartlashtirish bilan o‘lchanmaydi. Muhim mezon — bir atama aytilganda barcha ishtirokchi bir xil biznes hodisasi, qoida va chegarani tushunishidir.
Tarjima qilinadigan ko‘p tilli interfeysda domen atamasi bilan foydalanuvchiga ko‘rsatiladigan label alohida boshqarilishi mumkin. Koddagi model ma’nosi tarjima matni o‘zgarganda buzilmaydi.
Bog‘liq tushunchalar
Domain-Driven Design, Bounded Context, Domain model, Entity, Value Object, BDD, Context map