Actualizado: se ha corregido el concepto, ya que se confundía con la definición de glosario, cuando se quería detallar que era algo más que un glosario.
En todas las empresas en las que he trabajado, siempre surge el problema de que, cuando sale algo nuevo o se crea un cierto programa, un sistema o una forma de trabajo, si la persona que la ha motivado no sabe su nombre: se la inventa.
Esto pasa con mucha frecuencia, y no es malo, pero es común que toda la empresa termine usando el vocablo en muy poco tiempo y, toda persona que entre nueva, si ese vocablo le parece desconocido o le sugiere otra cosa distinta, le lleve a confusión hasta que se lo expliquen.
Para esto se suelen hacer glosarios o lo que, en ingeniería del software se conoce como: Modelo de Dominio.
Este documento tiene varias partes, una de ellas se especifica como un glosario, estando ordenado alfabéticamente, y recogiendo todas las palabras que se usan, comúnmente en el entorno profesional en el que se mueve la empresa, y las palabras referentes a productos y servicios específicos que se comercializan o adquieren por parte de la empresa. Otra de las partes es la relación que hay entre conceptos que se manejan en la empresa, definición de características de cada uno de los elementos y restricciones de uso de los mismos.
Ceñirse a estándares es una forma de no necesitar un modelo de dominio, pero es complicado no saltarse las normas alguna que otra vez, por lo que, aún tomando precauciones de llamar a todo por su nombre, es conveniente y productivo, sobre todo para las nuevas incorporaciones o subcontratas, tener este documento disponible.
A mí se me da a menudo la circunstancia de hablar con los de “cuello blanco”; aquí si que se echa de menos un glosario común para entenderse. Sobre todo si hablas de cosas como layout, evento, sesión… y luego pasas a cabecera, acceso… al final nadie se entiende
Me parece que te estas equivocando man, el modelo de dominio es una representacion de las clases que interactuan en el sistema, en las cuales aparecen sus atributos y la relacion numerica que hay entre ellos, sirve para ver que cosas estan dentro del sistema y cuales no.
En la Universidad el aspecto del Modelo de Dominio es mucho más amplio de como se intenta simplificar por técnicas como RUP. Un modelo de dominio, intenta reflejar el mundo visto por parte del cliente, intenta dar una visión del mundo que maneja el cliente, a modo de entender porque se toman las decisiones que se toman y cómo poder realizar un software que tenga realmente valor para el cliente.
El hecho de simplificarlo en representar las clases que interactúan con el sistema, me parece un poco incorrecto, ya que ni tan siquiera son clases, propiamente dichas. RUP usa UML, el diagrama de clases, para captar los elementos físicos y lógicos que determinan el mundo del cliente (el dominio en que se mueve).
Quizás el artículo haya recogido, también de forma errónea, un acercamiento más a lo que es un glosario, que a lo que es una descripción detallada del dominio, mea culpa, lo revisaré de nuevo en cuanto tenga un tiempo. Gracias por el comentario.
alguien tiene una guia con la que pueda ver como se trabaja con el modelo del dominio?
El modelo de dominio se suele representar mediante diagramas de clase de UML, esto puede verse, con ejemplos en la siguiente presentación:
http://lsi.ugr.es/~ig1/isoo/larman/Modelo%20del%20dominio.pdf