Al diseñar un sistema, ¿es una buena práctica atender el diseño en torno al marco que utilizará?

Al desarrollar un sistema o aplicación que planea usar con un determinado marco, ¿es mejor diseñar el sistema sin el marco en mente, o es mejor diseñar el sistema con la mentalidad? "Bueno, el marco tendría un tiempo más fácil con este".

development-process systems

— Robert Pounder
fuente

¿De qué tipo de marco estás hablando? ¿Te refieres a un marco específico de nicho de negocio que está diseñado para resolver problemas muy específicos de dominio para una industria en particular? (p. ej. médico, nuclear, defensa, aviación, etc.). ¿O estás hablando de marcos de uso general diseñados para resolver problemas técnicos?

— Ben Cottrell

marcos de uso general diseñados para resolver problemas técnicos

— Robert Pounder

Pequeña escala por falta de tiempo (estoy en el trabajo, puedo elaborar más adelante): estoy escribiendo un sistema que genera correos electrónicos basados en diseños. - Si escribiera esto en Laravel, probablemente usaría su "hoja" de motor de plantillas para diseñar los correos electrónicos, lo que haría que el diseño del sistema fuera mucho más simple en términos de flujo. Sin embargo, tendría que comenzar a escribir un motor de plantillas si lo estuviera haciendo PHP vainilla, o encontrando otro sistema de plantillas alternativo adecuado. Se agregaría al proceso de diseño, al que también se refiere la pregunta.

— Robert Pounder

Esta pregunta va a generar un montón de respuestas muy diferentes porque tanto "marco" como "diseño" son palabras sobrecargadas con múltiples significados en nuestra industria. Además, incluso para una definición única de marco como "marcos de propósito general diseñados para resolver problemas técnicos", dependerá del marco específico: algunos marcos son más obstinados que otros.

— stannius

Sería muy malo ser atropellado por un autobús mientras está perdido en sus pensamientos tratando de diseñar un vehículo de transporte público con ruedas.

Respuestas:

Su diseño debe satisfacer las necesidades de los clientes lo más cerca posible. Recuerde que el diseño incluye pequeñas cosas como:

Experiencia de usuario
Funcionalidad
Cómo se comunican las piezas de su aplicación (ya sea consigo mismo o con entidades externas)

Ninguna de estas cosas debe ser dictada por el marco. Si está claro que lucharás contra tu marco para lograr estos objetivos, entonces eliges un nuevo marco que te ayudará a lograr esos objetivos antes de comenzar a escribir código.

Una vez que haya elegido un conjunto de herramientas apropiado (el marco es una herramienta), le recomiendo usar las herramientas de la forma en que están diseñadas para ser utilizadas. Cuanto más se desvíe del diseño del marco, más aumentará la curva de aprendizaje para su equipo y mayores serán las posibilidades de que algo salga mal.

En breve

Diseñe para sus usuarios
Elija las herramientas apropiadas para lograr su diseño
Use sus herramientas de la forma en que están diseñadas para ser utilizadas

Pensamientos adicionales:

Después de más de 20 años de ingeniería de software y utilizando varios marcos, he aprendido un par de lecciones. Todos los marcos son un arma de doble filo: ambos limitan y habilitan. El problema con la decisión de su marco antes de mirar los 3 grandes que mencioné anteriormente es que podría estar comprometiendo una buena experiencia de usuario para una mediocre (en el mejor de los casos). O puede verse obligado a desviarse del diseño de marcos para lograr alguna funcionalidad específica.

— Berin Loritsch
fuente

Entonces necesita hacer algunas negociaciones con el cliente. Explique lo que puede y no puede hacer con las restricciones que han impuesto. Proponga cómo eso puede cambiar si elige X framework. Es posible que no estén dispuestos a cambiar y estén dispuestos a vivir con una experiencia degradada. O pueden decidir que sabes lo que estás haciendo y confiar en ti. Eso depende del cliente. Al final del día, manejas sus expectativas.

— Berin Loritsch

Aquí parece haber cierta confusión entre los diferentes niveles de diseño: diseño del sistema y diseño detallado. Para mí, esta pregunta era sobre el diseño detallado (el método de implementación) en lugar del sistema (interfaces, concurrencia, volumen de datos, interfaz de usuario, tipo de usuario).

— Gusdor

Si la pregunta gira en torno al "diseño técnico", entonces el lenguaje y el sistema operativo pueden tener algunas inferencias en el diseño. Pero aún así, el diseño no es implementación. Si está pensando en las capacidades de Frameworks, no es diseño, es implementación. Si basa sus decisiones de diseño en las fortalezas del marco, prepárese para sufrir su debilidad. Y cuando la debilidad cumple con los requisitos, tienes un gran problema. Las compañías más grandes no construyeron sus propios marcos por placer.

— Laiv

@Laiv ¡Gran comentario! Realmente, es "algo y algo". Una pistola de clavos y una pistola de tornillos pueden sujetar cosas, una es más reversible que la otra y también funciona más lentamente y es más compleja. Cada elección que hace la gente es inevitablemente una compensación. Paga su dinero y se arriesga.

@RobertPounder, es una herramienta cuya idoneidad para una solución debe decidirse al diseñar el sistema. Entiendo cómo los marcos pueden influir en el diseño, pero no deberían dictarlo.

— Berin Loritsch

Los marcos influyen naturalmente en el diseño de módulos y subsistemas específicos (como una interfaz gráfica de usuario). Como se mencionó en la otra respuesta, tendrá un momento difícil si se encuentra luchando contra los marcos elegidos.

Sin embargo, en términos más generales, debe evitar dejar que un solo marco o tecnología dicte o impulse el "panorama general" de la arquitectura general del sistema. La mayoría de los marcos de aplicaciones de uso general no fomentan esto, así que si te encuentras escribiendo todo tu sistema alrededor de un marco, entonces probablemente estés haciendo algo que los autores de ese marco no tenían la intención.

Probablemente usará muchos marcos diferentes para resolver diferentes problemas; A medida que su sistema se vuelve más complejo, debe tener cuidado de no construir The Big Ball Of Mud . Siempre que sea posible, mantenga su sistema modular y sin apretar. Algunos frameworks pueden mantenerse mejor detrás de las abstracciones escribiendo envoltorios y adaptadores que 'oculten' los flujos de trabajo específicos de Framework lejos de otros componentes. Los kits de herramientas de la GUI tienden a servir solo a la funcionalidad de la GUI front-end, por lo que esos módulos de la GUI deben mantenerse alejados del resto del sistema.

Los marcos de uso general (como los marcos de UI, los marcos de capa de datos, etc.) no existen para prescribir la arquitectura completa de su sistema; a lo sumo, pueden prescribir el diseño de un componente o módulo; por ejemplo, algunas tecnologías GUI están orientadas a patrones MV * particulares.

La arquitectura general de su sistema debe estar impulsada principalmente por los requisitos de su negocio. . Puede encontrarse apoyado en gran medida en una herramienta en particular (por ejemplo, una herramienta de middleware de mensajería o un marco ORM) para unir todo, pero si ha encapsulado el marco en una abstracción como una clase de 'servicio', usted es menos probable que te encuentres limitado por ese marco cuando encuentres sus limitaciones.

Intente tener en cuenta lo siguiente para su diseño de imagen general:

Apunta a construir software modular
Considere la separación de preocupaciones al escribir cada módulo y componente
Considere la arquitectura de varios niveles para separar el sistema en capas
No construyas abstracciones con fugas
Los acrónimos de esta pregunta relacionada : ¿Cómo se clasifican DRY, KISS, SOLID, etc.?

— Ben Cottrell
fuente

A veces parece que a algunos autores de marcos no les importa en absoluto que sus usuarios escriban código de aplicación estrechamente junto con el marco.

— VENIDO del

@COMEFROM: los desarrolladores animarían a acoplar firmemente su código a un marco porque suponen que usted eligió su marco para resolver los mismos problemas para los que lo diseñaron en primer lugar.

— JeffO

Pasaste un poco fuera de tema, pasando de principios de diseño a principios de codificación, pero entiendo lo que dices, ¿qué pasa si el requisito comercial es que se use un cierto marco? (piense en el outsourcing de la compañía y los desarrolladores internos solo conocen un idioma) Creo que debería haberlo aclarado en la publicación original.

— Robert Pounder

@RobertPounder El verdadero punto al que había estado tratando de llegar (tal vez no muy bien) es que a veces hay una tendencia para que las personas usen marcos particulares como una 'base' para toda su aplicación, lo que inevitablemente conduce a la lógica de negocios y otros el código no relacionado se fusionó de manera inapropiada con ese marco, por ejemplo, la lógica de negocios se combinó con los controles de la interfaz de usuario solo porque era rápido y fácil en ese momento. Es muy fácil hacer eso, así que es algo de lo que debemos tener cuidado

— Ben Cottrell

Debo estar en desacuerdo con @nocomprende aquí; no todos los requisitos futuros se pueden predecir, pero a veces los sistemas se reescriben simplemente porque el software anterior es demasiado difícil de extender / mantener .

— SeldomNeedy

Sí, debe atenerse lo más posible a lo que el marco "le dice" que haga.

La razón es simplemente que cuanto más se apegue a la forma de "pensar" de los marcos, más fácil será hablar con otros desarrolladores sobre sus problemas / ideas que también usan ese marco.

Aumenta la interoperabilidad y la facilidad de uso para otras personas que lo usan más tarde, comprenderá e incorporará tutoriales o soluciones comunes mejor si se apega a la filosofía subyacente de lo que esté usando.

La única buena razón por la que puedo pensar por qué "rompería" el marco es que necesita absolutamente algo que no puede proporcionar dada su configuración / aplicación "predeterminada" de principios. Pero entonces, podría no ser el marco adecuado para comenzar.

Básicamente, esto también puede aplicarse a otras decisiones. Se debe utilizar la lengua que está utilizando en la mayor medida que está destinado a ser utilizado, porque hace las cosas más fáciles si se habla el mismo idioma que todos los demás.

— FP
fuente

Es posible que deba revisar su respuesta debido a los cambios de la pregunta. Su respuesta en realidad no responde la pregunta del OP.

— Laiv

@Laiv No veo cómo no responde la pregunta, aunque podría no coincidir con tu opinión sobre el tema, sigue siendo una respuesta. Lo invitamos a escribir su propia respuesta para mostrar la naturaleza conflictiva del tema en cuestión.

— FP

Disculpe si no me expliqué bien. No soy tan fluido en inglés como me gustaría ser. Solo quería decir que, en mi opinión, la pregunta y su respuesta hablan sobre cosas diferentes. Si crees que no, está bien. No voy a discutir eso. Eso es.

— Laiv

Esto es absolutamente todo. Es similar a cómo funcionan los lenguajes específicos de dominio y las ideas similares. Sus productos están formados por la herramienta (Framework) y no al revés. El marco "gana". Si no puedes casarte con él, elige uno diferente. (Sugerencia: no hay un marco ideal . Solo

Su diseño debe influir en el marco que elija (si corresponde), y no al revés.

— RubberDuck