Teoría: Ontología

Los programas que los programadores escriben siempre se crean para un dominio específico. Por ejemplo, el software de contabilidad se basa en las reglas de contabilidad, mientras que un sitio web para ver series se basa en conceptos de la industria televisiva, como "temporada" y "episodio". Lo mismo ocurre con todo lo demás: reserva de vuelos, hoteles, búsqueda de tours, venta y compra de automóviles, y así sucesivamente.

Comprender el dominio para el cual estás escribiendo el programa es tan importante como saber programar. Esto no significa que debas conocerlo en detalle, a veces el dominio puede ser realmente complejo (como la contabilidad o la producción tecnológica), pero aún se requiere una comprensión general.

Tomemos Códica como ejemplo, ya que estás bastante familiarizado con él. Conoces bastante bien su dominio, aunque probablemente no hayas pensado en él de la manera en que lo haremos ahora. En primer lugar, para comprenderlo, debemos identificar los conceptos clave. En el caso de Códica, estos suelen ser "curso" y "lección", pero en realidad hay muchos más. En el caso de Códica, también podemos identificar la profesión, el desafío (práctica después del curso), la revisión de código, el cuestionario (conjunto de preguntas y respuestas), el participante del curso (te conviertes en participante cuando te unes a un curso), el proyecto. Esta lista podría continuar. Es posible que te sorprenda, pero en Códica hay más de 200 conceptos similares, que también se llaman "entidades", y todos están descritos en el código.

Las entidades tienen relaciones entre sí. Por ejemplo, un cuestionario contiene (agrega) preguntas. Y cada pregunta, a su vez, contiene respuestas. Una profesión consta de cursos, y los cursos constan de lecciones, que a su vez constan de teoría, cuestionarios y práctica. Estas relaciones tienen nombres específicos. Por ejemplo:

• Una lección solo puede estar en un curso, pero un curso puede contener muchas lecciones. Esta relación se llama "uno a muchos" (one-to-many o o2m).
• Varios usuarios pueden tomar un curso y un usuario puede tomar muchos cursos. Esta relación se llama "muchos a muchos" (many-to-many o m2m).
• Menos común es la relación "uno a uno" (one-to-one o o2o). En Códica, esto se aplica a la relación entre una lección y un ejercicio.

En la realidad, todo es un poco más complicado, porque la misma entidad puede verse completamente diferente desde el punto de vista de diferentes sistemas. El usuario de Códica desde el punto de vista de un contador (¡y tenemos un contador!) y desde el punto de vista del soporte son dos cosas muy diferentes.

La descripción de los objetos en el dominio y las relaciones entre ellos se llama ontología del dominio. Los expertos en el campo correspondiente (un contador en contabilidad, un profesor en educación) conocen bien esta ontología, aunque a menudo la entienden de manera intuitiva e informal. En la práctica, los programadores (o analistas de negocios y gerentes) se comunican con los clientes, que a veces actúan como expertos y construyen juntos una ontología formal (esto ocurre constantemente durante el desarrollo del proyecto y no se destaca como una etapa separada de diseño). Es decir, se definen términos específicos, se acuerda lo que significan y cómo están relacionados entre sí. Luego, el programador utiliza un modelo de entidad-relación (ER) para crear el modelo de datos necesario. El modelo ER se utiliza en el diseño de alto nivel (conceptual) de bases de datos. En esta etapa, los cimientos de la arquitectura de la futura aplicación ya se están formando.

No siempre es posible decir de manera inequívoca qué relación existe entre dos entidades. A veces, los programadores piensan de antemano y crean relaciones más complejas, como m2m en lugar de o2m, lo que afecta la complejidad del código. Cuanto más compleja es la relación, más código se necesita y más costoso es crearlo y mantenerlo. La complejidad de las relaciones se puede describir de la siguiente manera (más a la derecha es más complejo): o2o, o2m, m2m. A veces, los programadores cometen errores al elegir una u otra relación, lo que generalmente indica una comprensión insuficiente del dominio. Aquí hay un ejemplo interesante. Supongamos que el sistema necesita implementar un usuario y un pasaporte extranjero. Intuitivamente, parece que hay una relación uno a uno entre estos conceptos: después de todo, un usuario puede tener un solo pasaporte extranjero. ¿Verdad? No del todo: el pasaporte puede cambiar si se pierde o si expira. Además, en algunos países se permite tener varios pasaportes extranjeros al mismo tiempo.

Por otro lado, el mundo real siempre es más complejo y completo que cualquier modelo. Y la tarea del programador no es crear un modelo universal y completo de un área determinada, sino comprender las necesidades comerciales específicas, identificar solo las partes significativas del dominio considerado y trasladarlas al código.

La forma en que se representan las entidades en el código varía según el lenguaje. Algunos definen tipos (usando ADT, interfaces o clases), otros utilizan estructuras, y otros solo proporcionan diccionarios (arrays asociativos) como opción.

La programación orientada a objetos (POO) está directamente relacionada con el tema que estamos discutiendo. A partir de la próxima lección, comenzaremos a estudiar diferentes dominios y construiremos modelos de datos adecuados, al mismo tiempo que exploramos nuevas capacidades de JavaScript.

El tema más completo se desarrollará cuando comencemos a estudiar ORM. Por ahora, es suficiente tener una comprensión general del dominio, las entidades y las relaciones. No olvides leer la información en los enlaces proporcionados, cuanto más preguntas surjan en esta etapa, mejor.