Ngôn ngữ phổ biến - xung đột giữa tính chính xác và khả năng sử dụng

10

Một phần cốt lõi của Thiết kế hướng miền là việc sử dụng nhất quán ngôn ngữ phổ biến trên toàn hệ thống - trong các cuộc hội thoại, mã, lược đồ cơ sở dữ liệu, giao diện người dùng, kiểm tra, v.v.

Tôi đang tham gia vào một dự án đã có ngôn ngữ tên miền được thiết lập tốt, được xác định bởi một tổ chức tiêu chuẩn quốc tế.

Tuy nhiên, công việc chúng tôi đang làm là dành cho một trang web công cộng và các thuật ngữ 'chính xác' cho tên miền không nhất thiết là cách công chúng thường sử dụng và hiểu chúng.

Sự thỏa hiệp mà chúng tôi đang sử dụng hiện tại là sử dụng các điều khoản 'chính thức' ở mọi nơi, ngoại trừ trong các tiêu chí chấp nhận của chúng tôi đề cập đến các thành phần UI, nơi chúng tôi sử dụng các tên không chính thức.

Điều này có vẻ như là một cách tiếp cận hợp lý?

documentation domain-specific-languages

— Andy chờ đợi
nguồn

Bạn có thể cung cấp một ví dụ? Tôi có thể đưa ra một câu trả lời chi tiết hơn sau đó. Bạn có cần đăng ký các thuật ngữ cho chúng hoặc có các thuật ngữ va chạm với tổng số ý nghĩa khác nhau không? Liệu có thể tìm thấy một điểm chung giữa các điều khoản không chính thức và ngôn ngữ miền?

— Falcon

1

Đã được một thời gian kể từ khi tôi đọc phần đó của cuốn sách Evans, nhưng tôi nghĩ ngôn ngữ phổ biến sẽ được sử dụng với chuyên gia tên miền? Tôi chắc chắn sẽ không mong muốn người dùng hiểu tất cả các thuật ngữ của chuyên gia tên miền vì vậy tôi chỉ trình bày cho người dùng những gì bạn đã đặt tên cho các tên không chính thức.

— Kaleb Pederson

7

Vâng, điều đó có vẻ hợp lý. Nếu đối tượng dự định không hiểu các điều khoản trong ngôn ngữ của bạn hoặc giải thích sai về chúng, thì khả năng sử dụng cho người xác nhận được ưu tiên.

Một chương trình hoặc nội dung mà người dùng thông thường không hiểu được rất ít giá trị. Hơn nữa, nếu bạn chỉ muốn trình bày cho họ một mẹo đơn giản về một tảng băng trôi vì họ không và sẽ không bao giờ là chuyên gia về miền.

Thông thường, khi bạn nói về tên miền trong quá trình phát triển thì mọi người đều hiểu ngôn ngữ vì nó chính xác và tất cả mọi người đều ở trong miền. Nhưng nếu giá trị doanh nghiệp được tạo ra bằng cách truyền đạt nội dung cho người ngoài của tên miền, thì hãy làm điều này càng đơn giản càng tốt. Sử dụng các từ và ngôn ngữ ít có khả năng bị hiểu nhầm và sử dụng chúng trong UI.

Giữ ngôn ngữ chính xác trong mã của bạn và để liên lạc với những người quan tâm đến tên miền. Đây là những người có thông số kỹ thuật và là người dùng chính của ứng dụng, là người bạn thảo luận về các chi tiết logic kinh doanh. Trong trường hợp hiếm hoi mà bạn thực sự thảo luận về hầu hết các chi tiết logic kinh doanh với người dùng không có nhiều manh mối về tên miền và bạn không cần đi sâu vào nó, sau đó kết hợp ngôn ngữ của họ với ngôn ngữ tên miền của bạn, cho rằng họ có một ngôn ngữ chung, không rõ ràng (có lẽ không phải vậy).

Nhưng hãy chắc chắn rằng các nhà phát triển frontend biết về các điều khoản không chính thức của bạn và các điều khoản tên miền tương ứng của họ.

— Chim ưng
nguồn

1

Tôi nghĩ cách dễ nhất để trả lời điều này sẽ là vẽ đường chính xác nơi bạn sẽ vẽ nó nếu bạn trình bày UI bằng một ngôn ngữ hoàn toàn khác.

Nếu người dùng cuối của bạn cần xem mọi thứ bằng tiếng Phạn, bạn sẽ kết nối sự khác biệt giữa giao diện người dùng và mã như thế nào (và giao tiếp nội bộ khác).

— John Fisher
nguồn

Nói hay lắm. Điều này chỉ ra "Vấn đề Humpty-Dumpty": các từ không chỉ là sự thay thế, chúng đề cập đến những thứ mà mọi người biết về độc lập với các từ và cách sử dụng chúng. Động vật hiểu ý tưởng về 'nhiệt độ' chẳng hạn. Chúng ta bị treo lên từ, khi chúng chỉ là biểu tượng cho các khái niệm. Các khái niệm là những điều quan trọng.