Ubiquitous Language - konflik antara kebenaran dan kegunaan

10

Bagian inti dari Desain Berbasis Domain adalah penggunaan yang konsisten dari bahasa di mana-mana di seluruh sistem - dalam percakapan, kode, skema basis data, UI, tes, dll.

Saya terlibat dalam sebuah proyek di mana sudah ada bahasa domain yang sudah mapan, yang ditentukan oleh organisasi standar internasional.

Namun, pekerjaan yang kami lakukan adalah untuk situs web publik, dan istilah 'yang benar' untuk domain tersebut tidak selalu bagaimana publik biasanya menggunakan dan memahaminya.

Kompromi yang kami gunakan saat ini adalah menggunakan istilah 'resmi' di mana saja, kecuali dalam kriteria penerimaan kami yang merujuk pada komponen UI, di mana kami menggunakan nama-nama informal.

Apakah ini tampak seperti pendekatan yang masuk akal?

documentation domain-specific-languages Andy Waite
sumber
Bisakah Anda memberikan contoh? Saya bisa memberikan jawaban yang lebih detail. Apakah Anda perlu membatasi syarat untuk mereka atau apakah ada istilah bertabrakan dengan makna yang berbeda total? Apakah mungkin untuk menemukan kesamaan antara istilah-istilah informal dan bahasa domain?
Falcon
1
Sudah lama sejak saya membaca bagian dari buku Evans, tapi saya pikir bahasa di mana-mana akan digunakan dengan pakar domain? Saya tentu tidak akan mengharapkan seorang pengguna untuk memahami semua terminologi dari ahli domain jadi saya hanya akan memberikan kepada pengguna apa yang Anda namakan nama-nama informal.
Kaleb Pederson

Jawaban:

7

Ya, itu masuk akal. Jika audiens yang dituju tidak memahami ketentuan bahasa Anda atau salah mengartikannya, maka kegunaan untuk pengguna akhir diutamakan.

Program atau konten yang tidak dipahami oleh pengguna biasa memiliki nilai yang kecil. Lebih dari itu, jika Anda hanya ingin memberikan mereka tip gunung es yang disederhanakan karena mereka tidak dan tidak akan pernah menjadi ahli domain.

Biasanya, ketika Anda berbicara tentang domain selama pengembangan maka semua orang mengerti bahasa karena itu akurat dan semua orang berada dalam domain tersebut. Tetapi jika nilai bisnis diciptakan oleh komunikasi konten kepada orang luar dari domain, maka lakukan ini sesederhana mungkin. Gunakan kata-kata dan bahasa yang paling tidak disalahpahami dan menggunakannya di UI.

Simpan bahasa yang akurat dalam kode Anda dan untuk berkomunikasi dengan orang-orang yang peduli dengan domain. Ini adalah orang-orang yang memiliki spesifikasi dan yang merupakan pengguna utama aplikasi, orang-orang yang Anda ajak mendiskusikan rincian logis bisnis. Dalam kasus yang jarang terjadi, Anda benar-benar mendiskusikan sebagian besar detail logis bisnis dengan pengguna yang tidak memiliki banyak petunjuk tentang domain dan Anda tidak perlu menyelami dalamnya, lalu memasukkan bahasa mereka ke dalam bahasa domain Anda, mengingat bahwa mereka memiliki bahasa yang sama dan tidak ambigu sama sekali (yang mungkin bukan masalahnya).

Tetapi pastikan bahwa dev frontend tahu tentang ketentuan informal Anda dan ketentuan domain terkait.

Elang
sumber
1

Saya pikir cara termudah untuk menjawab ini adalah dengan menggambar garis persis di mana Anda akan menariknya jika Anda menyajikan UI dalam bahasa yang sama sekali berbeda.

Jika pengguna akhir Anda perlu melihat hal-hal dalam bahasa Sanskerta, bagaimana Anda menjembatani perbedaan antara UI dan kode (dan komunikasi internal lainnya).

John Fisher
sumber
Kata baik. Ini menunjukkan "Masalah Humpty-Dumpty": kata-kata bukan hanya substitusi, kata-kata itu merujuk pada hal-hal yang diketahui orang secara independen dari kata-kata dan penggunaannya. Hewan memahami gagasan 'suhu' misalnya. Kita terpaku pada kata-kata, ketika itu hanya simbol untuk konsep. Konsep adalah hal yang penting.