Hace un año, Maxim Arshinov (marshinov) hizo una presentación "Diseño instantáneo". Gran informe, orador carismático, materiales útiles al final. Este informe cambió mi comprensión de lo que estaba haciendo: ¿cuál de nosotros no ha tratado de aplicar intuitivamente la arquitectura de tuberías? ¡Y luego hay soluciones elegantes multiplicadas por DDD! Esto comenzó mi viaje como evangelista en diseño de dominio específico.

DotNext 2019 Moscú llegará pronto. Como siempre, estamos esperando una revisión de las nuevas características, el intercambio de experiencias, las mejores prácticas, las soluciones arquitectónicas; para esto, a todos nos encantan las conferencias. En la lista de informes se encuentra la tienda "El modelo de brillo y pobreza del sujeto", que me llamó la atención. Cita de la página:

Fowler y Evans consideran que el modelo anémico es antipatrón. Sin embargo, muchas bases de código con las que ha trabajado el hablante se implementan al estilo de un modelo anémico. El informe está dedicado a comparar las fortalezas y debilidades de ambos enfoques y los detalles no obvios de la implementación del modelo de dominio en el paradigma OOP y en el estilo funcional.

La producción misma hace pensar que ha surgido una crisis en el desarrollo del movimiento DDD. Un pequeño análisis de las disfunciones de uso y las razones de tales distorsiones debajo del corte.

Disfunciones del uso del diseño orientado a temas.

La situación actual tiene algún desarrollo histórico. Consideremos por etapas cómo se desarrolló la situación.

Promoción

Maxim, en mi opinión, es el desarrollador más famoso de la comunidad, que durante muchos años promovió DDD de manera competente, hablando sobre el concepto y el uso. ¡Honrarlo y alabarlo! Y le doy a Arshinov como ejemplo, solo porque lo considero el mejor orador de dotnext en este momento.

Disfunción # 1: Rentabilidad

marshinov ha escrito varios artículos sobre el costo de implementar prácticas DDD. La conclusión es simple: el diseño orientado a temas es costoso. Y los juicios son justos: el propio Evans en su libro señala que el equipo debe ser muy hábil y, por lo tanto, costoso. Además, estas son mejoras continuas, lo cual es costoso para una empresa. Bien revela este artículo del tema de Martin Fowler sobre los costos de la arquitectura . Me atrevo a suponer que la cuestión de cuánto quiere gastar una empresa en recursos es la solución de sus problemas, en primer lugar, para sí misma. Y el cliente no resuelve ningún problema importante por sí mismo, incluso SOLID no podrá venderlo.

Es muy importante comprender el antagonismo de los requisitos comerciales y las decisiones arquitectónicas. Las empresas necesitan la solución más barata que cubra sus necesidades (y mejor la primera vez y para siempre). Los equipos desean crear herramientas y soluciones que resuelvan de manera más correcta, rápida y bella los problemas comerciales, pero especialmente la tarea de la adaptabilidad a los cambios. La naturaleza de estas necesidades (de hecho, contradicciones polares) es muy dialéctica, lo que a su vez significa que es imposible cumplir requisitos complejos sin elaborar la arquitectura, y no se pueden construir condominios en lugar de una caseta de perro. No, por supuesto, todo es posible. Pero el hecho es que las altas demandas, por un lado, dan lugar a las correspondientes por el otro. Al igual que la debilidad patológica de un lado, limita el otro.
Y así, en un intento de igualar el negocio, se formó un segundo desastre ...

Disfunción # 2: Diseño instantáneo, también conocido como Modelo anémico, también Consentimiento

Obviamente, cierta comunidad de programadores está tratando de llevar a las masas de prácticas un diseño orientado a temas más barato, reduciendo costos y aplicando nuevas técnicas: programación ferroviaria, tuberías, modelo anémico. Un enfoque genial, muchos consejos, esto puede enseñarse a cualquier programador: "aquí tiene SeedWorks con interfaces, impleméntelas y todo estará". Y funciona! Pero esto no es DDD.

No entiendes del todo a Evans.

• ¿Quién no alaba a Klopstock? ¿Pero lo leerán todos? No Queremos que se nos venere menos, ¡pero leamos más diligentemente! (Lessing)

Te lo explicaré ahora.

El modelo anémico es un antipatrón

El hecho es que en la ciencia hay dos métodos de investigación: descriptivo y analítico (hola Adam Smith). Cuando hacemos el modelo anémico, simplemente describimos lo que vemos y vivimos con él tal como es. Esto refleja un negocio y es suficiente para aprovechar una oportunidad de negocio. Un principio importante descrito por Evans no es desperdiciar recursos en un sistema ideal, sino simular el proceso tal como es, y solo entonces comenzar una refactorización profunda. ¿Y en qué punto con el modelo anémico podemos pasar a una refactorización profunda? ¿Se supone que debe comenzarlo? Me parece que la respuesta será negativa, y el modelo aquí se mantuvo como atavismo.

¡Eso es solo que el modelo en sí mismo no es importante! ¡Los patrones tácticos no son importantes! Los contextos limitados, un lenguaje único y una estructura a gran escala son importantes. Es por eso que es necesario acercarse a la entidad comercial desde el lado analítico, describiendo la raíz de agregación, los objetos de valor, los métodos comerciales y, como resultado, comprender los límites de un contexto limitado.

Por un lado, un modelo anémico y una solución barata es bueno, porque los programadores principiantes comprenderán una nueva dimensión en la programación: los objetos comerciales. Sin embargo, tomar una posición similar te está yendo mal por ti mismo. Al contratar a un programador más débil cada vez que puede hacer lo mismo que copiar y pegar, ¿tiene un argumento para que la empresa busque un empleado más fuerte?

Pero no podría terminar con el final sin gloria de la idea DDD.

Disfunción # 3 La vida después de los objetos comerciales, también conocida como complicación de las herramientas.

En la primavera de 2019, Maxim y Wagib nos contaron cómo no surgieron las características de F # en C #, cómo hacer que el modelo correctamente en F # sea más fácil, sobre cómo en el funcionalismo no violar la POO. Ahora las masas podían creer que DDD no solo no era asequible para ordenar música, sino para todos los mortales, sino solo para aquellos que conocían la programación funcional.

Escuche dónde conducen todos: ahora el diseño orientado a temas es costoso, puede escribir de manera efectiva solo en F #, y generalmente funciona a veces, a veces. No hay una leve impresión de que de esta manera los autores de libros y artículos nos distraigan de lo más importante en DDD, atrayendo al juego con patrones tácticos ideales. Y deben ser hermosos y lamidos, de lo contrario ...

Por supuesto, no hay otra manera. Todas estas abstracciones son importantes en una conversación de BrainSrorm, cuando todos necesitan entender todo muy claramente. O si encuentra gerentes y analistas que analizarán su código, un solo idioma (si el código es UL).

Sin embargo, como se mencionó anteriormente, lo contrario buscará su propio camino. El enfoque se ha arraigado donde la empresa está dispuesta a pagar por el desarrollo de código funcionalmente no obvio: esto es solo un nicho de mercado, no una regla.

Lo que es absolutamente desagradable aquí es la simple naturaleza humana de la actitud hacia los logros: las personas aprecian tales logros en sí mismos, sin darles un formulario o una aplicación aplicada. Y aquí la lista puede ser larga. Einstein nos dio STO, GR, FE, es un excelente científico, pero pregúntale a la persona promedio sobre el movimiento relativista, el tiempo: no necesita a Einstein, pero en una conversación "inteligente" uno podría mencionar que todo es relativo. Pregúntele a una persona sobre Freud, un gran psicólogo que ha hecho un gran progreso en la ciencia, si esta persona usa la psicología, por ejemplo, para interpretar la pesadilla de ayer; no lo hará, pero algún día mencionará la sexualidad y la psicología de las masas. Marx es el que hizo la ciencia de la sociología y la historia, pero nadie necesita el socialismo científico, pero todos pueden hablar de impuestos progresivos y democracia honesta. El diseño orientado a problemas tampoco tiene forma: Eric Evans nos ha abierto nuevas alturas, proporcionando una excelente herramienta para reducir la complejidad del software, pero aparentemente no está claro cómo usar DDD y qué hacer, y en general no funciona en absoluto.

No sé qué pasa con el resto, pero con el diseño orientado a temas puede comprender las razones de los malentendidos.

Las razones de la crisis de uso.

Los principios del diseño orientado a temas son muy tentadores, lógicos y holísticos. Aquí todo está cerca: Agile, CI, SOLID, GRASP, todo lo mejor que se les ocurrió a los desarrolladores. Sin embargo, no es suficiente creer en DDD, o negocios, o experiencia. Muchas personas de la comunidad, solo desarrolladores de integradores y oficinas de outsourcing, tienen la impronta de los valores comerciales en su trabajo, y con todo el deseo de que no puedan probar los métodos y prácticas líderes, porque el precio de estos ensayos y errores no está incluido en la lista de precios, es un final completamente materialista.

No quedan absolutamente nada para tales comandos, excepto cómo rentabilizar la programación, utilizando enfoques más simples, contratando desarrolladores de manera más económica, pero un modelo anémico se puede enganchar "por media pulgada". Y si usted es el desarrollador de uno de los desarrolladores que vienen por una hora, no tiene perspectivas significativas, debe completar el pedido, y la creatividad se fomenta solo en el proyecto Github en el hogar. DDD no es un lujo para un arquitecto, no un alarde de clientes: el nivel de equipo en una Enteprise separada. Debe tener en cuenta lo siguiente: mientras está en una relación de producción con quienes venden su trabajo especializado a quienes pagan mejor, solo hará lo que pagó el cliente: la implementación de las tareas comerciales. Desafortunadamente, probar las mejores prácticas no siempre se encuentra en el plano de estas tareas.

Resumen

DDD siempre se puede probar si está describiendo objetos del mundo real. Este enfoque se puede aplicar en PHP, y en VBA, y 1C (y los desarrolladores aplican). El problema de aplicar el enfoque es más probable en el plano de comunicación entre las personas, y es más probable que la tecnología ayude. ¡Comunícate, intenta, enseña a otros! Impulsar Softskills, solidaridad, unidad de propósito. DDD es solo una técnica de trabajo en equipo.

Y la próxima vez que piense a dónde ir para una entrevista, piense cuidadosamente en lo que elige: una empresa que revende sus habilidades sin piedad o quién realmente las necesita para resolver problemas específicos. Está en su poder ayudar a una empresa así a ser mejor, probar métodos y enfoques proporcionados, formar un equipo muy unido y cumplir su misión como programador. Esto último es especialmente importante, porque para las nuevas tecnologías y productos, muchos han olvidado el propósito original de esta profesión.

Sea como fuere, queda por esperar que en un intento de tocar las prácticas líderes, DDD no se transformará en ninguna otra dirección por conveniencia de los clientes y equipos. Espero con interés el próximo informe.

PD El propósito del tema es una invitación a una discusión. No tiene ningún propósito menospreciar el mérito de ningún miembro de la Comunidad DDD. Con respeto, trato a todos los representantes, lo que no elimina los problemas del desarrollo.