"Código en el lenguaje de dominio"

Consejos de programación para #programadores.

-----------------------------------------------------------------------

LIBRO: 97 COSAS QUE TODO PROGRAMADOR NECESITA SABER.

POR: KEVLIN HENNEY.

-----------------------------------------------------------------------

11° "CÓDIGO EN EL LENGUAJE DE DOMINIO":

Imagina dos bases de código. En una te encuentras con:

if (portfolioIdsByTraderId.get(trader.getId())

.containsKey(cartera.getId())) {...}

Te rascas la cabeza, preguntándote para qué podría ser éste código. Parece ser que se obtiene una identificación de un objeto comerciante; usando éso para obtener un mapa de un, bueno, mapa de mapas, aparentemente; y luego ver si otra identificación de un objeto de cartera existe en el mapa interior. Te rascas la cabeza un poco más, buscas el declaración de portfolioIdsByTraderId y descubres ésto:

Map<int, Map<int, int>> portfolioIdsByTraderId;

Gradualmente, te das cuenta de que podría tener algo que ver con si un comerciante tiene acceso a una cartera en particular. Y, por supuesto, encontrará la misma búsqueda fragmento -o, más probablemente, un fragmento de código similar pero sutilmente diferente- siempre que a algo le importe si un comerciante tiene acceso a una cartera en particular.

En la otra base de código, te encuentras con esto:

if (trader.canView(cartera)) {...}

Sin rascarse la cabeza. No necesita saber cómo lo sabe un comerciante. Tal vez hay uno de estos mapas de mapas escondido en algún lugar dentro. Pero eso es el negocio del comerciante, no el suyo.

Ahora, ¿en cuál de esas bases de código preferirías trabajar?.

Érase una vez, sólo teníamos estructuras de datos muy básicas: bits y bytes y caracteres (realmente solo bytes, pero pretenderíamos que fueran letras y signos de puntuación). Los decimales fueron un poco complicados porque nuestros números de base 10 no funcionan muy bien en binario, por lo que teníamos varios tamaños de tipos de coma flotante. Entonces vino matrices y cadenas (realmente sólo matrices diferentes). Luego tuvimos pilas, colas, hashes, listas enlazadas, listas de saltos y muchas otras estructuras de datos interesantes que no existen en el mundo real. La "ciencia de la computación" se trataba de gastar mucho esfuerzo en mapear el mundo real en nuestras estructuras de datos restrictivas. Los verdaderos gurús incluso podían recordar cómo lo habían hecho.

¡Entonces tenemos tipos definidos por el usuario! OK, esto no es una noticia, pero cambia el juego un poco. Si su dominio contiene conceptos como comerciantes y carteras, puede modelarlos con tipos llamados, por ejemplo, Trader y Portfolio. Pero algo más importante que ésto, puedes modelar las relaciones entre ellos utilizando el dominio términos, también.

Si no codifica usando términos de dominio, está creando un tácito (léase: secreto) entendiendo que este int aquí significa la forma de identificar a un comerciante, mientras que ese int de allí significa la forma de identificar una cartera. (Mejor no para confundirlos!) Y si representa un concepto de negocio ("Algunos comerciantes no pueden ver algunas carteras, es ilegal") con un algorítmico fragmento, digamos, una relación de existencia en un mapa de claves, no está haciendo el chicos de auditoría y cumplimiento cualquier favor.

El próximo programador que venga podría no estar al tanto del secreto, así que ¿por qué no hacerlo explícito? Usar una clave como una búsqueda de otra clave que realiza una control de existencia no es terriblemente obvio. ¿Cómo se supone que alguien intuya?.

¿Ahí es donde se implementan las reglas comerciales que previenen el conflicto de intereses? Hacer que los conceptos de dominio sean explícitos en su código significa que otros programadores pueden recopilar la intención del código mucho más fácilmente que tratando de adaptar un algoritmo a lo que entienden sobre un dominio. También significa que cuando el modelo de dominio evoluciona, y lo hará, a medida que comprenda el dominio crece: está en una buena posición para hacer evolucionar el código. Junto con una buena encapsulación, hay muchas posibilidades de que la regla exista en un sólo lugar y que puede cambiarlo sin que ninguno de los códigos dependientes sea más sabio.

El programador que llega unos meses más tarde para trabajar en el código, te lo agradecerá. El programador que llegue unos meses después, podrías ser tú

-Dan North-