"유비쿼터스 언어 문서"를 소프트웨어 사용자 정의 프로젝트로 취급 할 수 있습니다. 문서 관리를 위해 일부 소프트웨어를 가져 와서 특정 요구에 맞게 조정해야합니다. 소프트웨어 프로젝트에서는 일반적으로 사용자 요구를 수집하는 것으로 시작하여 정보 아키텍처 및 디자인 솔루션을 구축 한 다음 구현을 진행합니다. 아래는이 프로세스의 예입니다.
사용자에게 필요한 것은 무엇입니까? 일부 조직에서는 서로 다른 도메인의 기능을 가진 사람들이 문제와 해결책을 설명하기 위해 공용 언어 방언을 사용하려고합니다. 이 방언은 어휘 (단어와 말의 표현)에 의해서만 정의 될 것입니다. 발음은 여기서 중요하지 않을 것이며 문법은 언어의 문학 형태를 기반으로하기 때문입니다. 방언을 문서화하려면 어휘 (용어집)를 관리하는 데 가장 적합한 문서 구조를 설계해야합니다.
사람들은이 문서를 사용하여 단어 또는 약어의 의미를 배우거나 동의어 또는 정의로 올바른 단어를 찾거나 도메인을 구성하는 모든 단어를 배우고 싶을 수 있습니다.
이러한 사용자 요구에 따라 위키는 실제로 좋은 선택입니다. 잘 맞아? Confluence 또는 MediaWiki와 같은 훌륭한 위키 시스템에서는 다음이 가능합니다.
- 각 용어에 대한 기사를 작성하십시오.
- 일부 템플리트에서 기사의 공통 구조를 정의하여 집계에 사용할 수있는 공통 섹션이 포함되도록하십시오.
- 다른 위키 기사에서 용어 정의에 대한 링크를 쉽게 추가하십시오.
- 용어 정의를 사용하여 집계 테이블을 작성하고 다른 문서에 포함하십시오.
현재 정보 아키텍처를 문서화하기 위해 Confluence를 사용하고 있으며 유비쿼터스 언어 정의가 그 일부입니다. 이 문서의 최상위 레벨은 도메인 기사입니다. 모든 응용 프로그램에는 보안, 지불 등 여러 도메인이 있습니다.이 도메인은 시스템과 사용자의 많은 상호 작용에 의해 정의되며, 유비쿼터스 언어를 통해 설명 할 수 있으므로 이러한 상호 작용의 정의를 별도의 서브 페이지 및 정의에 넣습니다. 상호 작용 페이지의 하위 페이지에서 이러한 상호 작용에 의해 도입 된 용어 예를 들어 어떤 시나리오가 도메인을 구성하고 어떤 용어가 정의되어 있는지 확인할 수 있도록 집계 페이지를 상위 페이지에 배치했습니다.
이 문서 구조가 완성되고 더 자세한 시스템 사양으로 넘어 가면 간단히 시나리오의 IA 및 UL 정의를 참조 할 수 있습니다. 예를 들어 "컴포넌트 A는 시스템 B와의 통합을 구현하여 Z (UL 링크) ".