유비쿼터스 언어-정확성과 유용성 사이의 충돌

10

Domain Driven Design의 핵심은 대화, 코드, 데이터베이스 스키마, UI, 테스트 등 시스템 전반에서 유비쿼터스 언어를 일관되게 사용하는 것입니다.

국제 표준기구에 의해 정의 된 이미 확립 된 도메인 언어가있는 프로젝트에 참여하고 있습니다.

그러나 우리가하는 일은 공개 웹 사이트를위한 것이며, 도메인에 대한 '올바른'용어가 반드시 대중이 일반적으로이를 사용하고 이해하는 것은 아닙니다.

현재 사용중인 타협은 비공식 이름을 사용하는 UI 구성 요소를 나타내는 승인 기준을 제외하고 모든 곳에서 '공식'용어를 사용하는 것입니다.

이것이 합리적인 접근법처럼 보입니까?

documentation domain-specific-languages

— 앤디 웨이트
소스

예를 들어 줄 수 있습니까? 더 자세한 답변을 드릴 수 있습니다. 용어를 포경해야합니까, 아니면 완전히 다른 의미의 충돌하는 용어가 있습니까? 비공식 용어와 도메인 언어 사이의 공통된 근거를 찾는 것이 가능할까요?

— 팔콘

1

에반스 책의 일부를 읽은 지 얼마되지 않았지만 유비쿼터스 언어가 도메인 전문가와 함께 사용되어야한다고 생각 했습니까? 나는 확실히 사용자가 도메인 전문가의 모든 용어를 이해하기를 기대하지 않기 때문에 사용자에게 비공식 이름이라고 불렀던 것만 제시 할 것입니다.

— Kaleb Pederson

7

예, 합리적으로 보입니다. 의도 한 독자가 귀하의 언어 용어를 이해하지 못하거나 오해하는 경우 최종 사용자의 사용 가능성이 우선합니다.

일반 사용자가 이해하지 못하는 프로그램이나 내용은 가치가 거의 없습니다. 더 나아가, 당신은 그들에게 빙산의 간단한 팁을 제시하고 싶다면 도메인 전문가가 아니며 결코 도메인 전문가가 아닐 것입니다.

일반적으로 개발 과정에서 도메인에 대해 이야기 할 때 모든 언어가 정확하고 모든 사람이 도메인 내에 있으므로 언어를 이해합니다. 그러나 컨텐츠를 도메인 외부인에게 전달하여 비즈니스 가치를 창출하는 경우 가능한 한 간단하게 수행하십시오. 오해 가능성이 가장 적은 단어와 언어를 사용하고 UI에서 사용하십시오.

코드에 정확한 도메인 언어를 유지하고 도메인에 관심이있는 사람들과 의사 소통하십시오. 이들은 스펙을 가지고 있고 애플리케이션의 주요 사용자 인 사용자이며 비즈니스 논리 세부 사항에 대해 논의하는 사람입니다. 드문 경우이지만 대부분의 비즈니스 논리 세부 사항을 도메인에 대한 단서가 많지 않고 도메인에 대해 자세히 알아볼 필요가없는 사용자와 실제로 논의한 다음 해당 언어를 도메인 언어에 통합해야합니다. 공통의 모호하지 않은 언어를 사용하십시오 (아마 그렇지 않을 수도 있습니다).

그러나 프론트 엔드 개발자가 귀하의 비공식 용어 및 해당 도메인 용어를 알고 있는지 확인하십시오.

— 매
소스

1

UI에 완전히 다른 언어로 표시하는 경우 그릴 위치를 정확하게 그리는 것이 가장 쉬운 방법이라고 생각합니다.

최종 사용자가 Sanskrit에서 내용을 확인해야하는 경우 UI와 코드 (및 기타 내부 통신)의 차이점을 어떻게 극복 할 수 있습니까?

— 존 피셔
소스

잘했다. 이것은 "Humpty-Dumpty Problem"을 가리킨다. 단어는 단순한 대용이 아니라 사람들이 단어와 그 사용법에 대해 독립적으로 알고있는 것을 의미한다. 동물은 예를 들어 '온도'라는 개념을 이해합니다. 우리는 단지 개념의 상징 일 때 단어에 매달립니다. 개념은 중요한 것입니다.