¿Cómo dejo de diseñar y comienzo a diseñar este proyecto según lo sugerido por mi líder? [cerrado]

En primer lugar, diría que la diferencia entre arquitectura y diseño es principalmente la semántica. Algunos equipos tienen puntos de control entre los dos. Su líder técnico define la arquitectura como antes del diseño y la arquitectura como una implementación independiente. A partir de eso, asumo que estamos hablando de diseño como en el modelo de cascada y no de Diseño industrial, lo que le ayudaría a diseñar el producto con vistas a los usuarios antes de llegar a la arquitectura de software. Creo que la arquitectura a menudo se desliza en el diseño y eso no es necesariamente algo malo, a menudo es muy útil para el arquitecto tener un conocimiento profundo de lo que es posible dentro del sistema en cuestión.

Habiendo dicho todo eso, necesitas algún consejo para la situación en la que te encuentras. Hay todo un mundo de arquitectura de software, artículos, libros, conferencias, pero generalmente estás buscando patrones y abstracciones. Sin más detalles sobre el proyecto solo puedo dar un amplio ejemplo. Por ejemplo, si estaba trabajando en integración, está la Arquitectura Orientada a Servicios ( SOA ) patrón donde se dividen partes del sistema en 'servicios' para que pueda trabajar con cada parte de una manera definida, en el programa web esto a menudo se implementa como servicios web (aunque no debería ser tan limitado a eso) ) y más recientemente el aumento de las API RESTful con JSON, una vez más diría que este es un diseño que proviene de la arquitectura de SOA. Yo diría que Model, View, Controller (MVC) es otro ejemplo de un patrón de arquitectura de uso común, que divide la responsabilidad de los componentes de un sistema para permitir el intercambio de piezas, para contener errores y pruebas.

Desde un nivel de 10,000 pies, si puede dibujarlo en una pizarra y explicárselo a un programador competente que no trabaja en su campo y no conoce su lenguaje de programación y los detalles de implementación actuales, entonces probablemente sea arquitectura. Si puede escribir un libro sobre él que le importe a cualquier persona ajena a su empresa, entonces probablemente sea arquitectura. Si encuentra su autoexplicación de los detalles y no puede generalizarlo a otras bases de código / empresas / industrias, entonces probablemente sea un diseño.

Estoy de acuerdo en que los dos ejemplos que da son el diseño de código y no la arquitectura. El primero porque creo que cuando dices que creaste un 'algoritmo' para cargar recursos, creo que te refieres a que diseñaste un conjunto de instrucciones para realizar esa tarea, y no que hayas diseñado un nuevo algoritmo que enseñarán en el primer año. COMSC el año que viene. En el segundo ejemplo, nuevamente estoy de acuerdo en que es diseño. Si me mostraras alguna de estas ideas, no podré usarlas en mi proyecto de software aleatorio. Tiene que ir a un "nivel superior", orientado a objetos (OO) en Java en lugar de que yo quiera que la clase de cliente sea una subclase de la clase de persona. Incluso hablar de Excepciones en general podría considerarse un nivel demasiado bajo (demasiado cerca de la implementación).

Para tratar de abordar los detalles que enumeras, creo que deberías pensar en cómo diseñar un CMS basado en la web. Wordpress tiene un códice de arquitectura del sitio donde hablan mucho sobre los detalles de implementación del diseño, pero se desprende claramente de su publicación que su arquitectura principal se centra en hacer extensible Wordpress con temas. Diseñar una interfaz clara para un tema tal que pueda ser escrito por alguien fuera de la empresa fue claramente una decisión de arquitectura que tomaron. Estos son el tipo de cosas en las que es bueno ponerse en papel al diseñar su solución "a largo plazo" (no temporal) para que todas las decisiones de diseño e implementación que se tomen durante el desarrollo (por parte de todos los desarrolladores, no solo del arquitecto) están en línea con esta idea.

Otros ejemplos de arquitectura para su situación:

1. Poner todo en máquinas virtuales, alojadas en un proveedor en la nube o en casa y tener instancias de máquinas sin estado, de modo que cualquier máquina que falla pueda ser reemplazada por una nueva instancia de una máquina virtual sin tener que copiar en ningún estado o perder cualquier información.
2. Construir en pruebas de fallas de producción en vivo desde el principio chaos simians .

Tal vez intente dibujar todo el sistema en una pizarra. Pruébelo en diferentes niveles de detalle, la primera placa podría ser GUI- > dispatcher- > backend- > DB o algo así, y luego profundizar hasta que empiece a usar pronombres.

La distinción entre estas dos ideas es realmente importante donde trabajo.

Lo que usted llama "arquitectura", nosotros llamamos "programación en inglés". Esto es en parte importante porque si no puede describirlo a un no programador, entonces algo está mal. Es posible que no entiendas el problema lo suficientemente bien O que resuelvas un problema "fantasma" (no se trata aquí).

Los términos utilizados para estos dos aspectos diferentes del diseño son a menudo diferentes, pero los principios se reconocen fácilmente en todas partes. Un aspecto (en su caso, el arquitecto, en mi caso, el diseñador), los programas en inglés, mientras que el otro (en su caso el "diseñador", en mi caso el "desarrollador") en un idioma particular. También se distinguen con bastante frecuencia como "diseño" y "implementación". El "diseño" es lo que se supone que debe lograr y la "implementación" es el código que lo hace posible.

Algunos ejemplos de lo que he trabajado:

La arquitectura de un programa es: necesitamos un administrador centralizado o un hub al que podamos agregar módulos fácilmente. Este administrador distribuiría eventos a todos los módulos registrados. Un módulo puede registrarse con el Administrador de eventos y, por lo tanto, publicar eventos en el resto del sistema y recibir los eventos que le interesan. Cada módulo tiene un "buzón" que puede verificar y vaciar a su gusto. Esto nos permitiría acomodar nuevos módulos que aún no sabemos que necesitamos.

No hay código allí. Podría estar escrito en cualquier idioma. La implementación no está dictada por esta descripción.

La arquitectura de otro proyecto es: necesitamos una manera de iniciar y detener otros programas de manera confiable sin esperarlos. Podríamos tener un gerente que sea responsable de un programa en particular. Simplemente podemos decirle que inicie o detenga su programa y el gerente se encarga de ello. Si a este otro programa se le pide que se detenga y no lo hace en un período de tiempo determinado, el administrador sabe cómo forzarlo para que se detenga y limpiar el desorden. El programa no se inicia ni se detiene por ninguna otra cosa, y se le puede preguntar al administrador si su programa se está ejecutando, está detenido o está esperando para detenerse. Esto nos permite continuar con las otras cosas que debemos hacer, al mismo tiempo que seguimos iniciando y deteniendo estos otros programas correctamente.

Nuevamente, aquí nada dicta la implementación, aunque algunas implementaciones son claramente más útiles que otras.

La diferencia entre diseño (lo que llamaríamos patrones o implementación) y arquitectura (lo que llamaríamos diseño) es que uno de ellos resuelve un problema de codificación / implementación y el otro resuelve un problema del mundo real. .

Tal vez esto ayude. Siempre he visto la antigüedad de un ingeniero como una cuestión de cuán grande es el problema que pueden resolver por sí mismos.

A grandes rasgos, para transmitir la idea:

• Puede darle a alguien nuevo para la programación tareas pequeñas y contenidas con muchas instrucciones explícitas sobre cómo debe integrarse la tarea con otras piezas

• Un desarrollador de nivel medio es alguien que puede tomar una descripción de una parte de una aplicación y hacerla funcionar dentro del contexto de esa aplicación.

• Un desarrollador senior puede crear una aplicación de tamaño medio desde cero, dentro de las limitaciones técnicas de una tienda.

• Un desarrollador más avanzado puede hacer eso, y hacer elecciones de tecnología en el camino sobre qué tecnologías usar para que funcione bien.

... pero esas no son reglas duras y rápidas. Y algunas personas salen por la puerta como IMHO "senior", incluso si tienen que pasar algún tiempo con un título diferente.

Lo que el arquitecto está preguntando es ver el problema incluso más generalmente que eso. Si tuviera que reunir varias aplicaciones para hacer que el sistema funcionara:

• ¿Qué aplicaciones y servicios necesitará?
• ¿Qué piezas interactúan con los clientes y cuáles interactúan entre sí?
• ¿Cómo se comunicarán?
• ¿Dónde almacenarán los datos?
• ¿Dónde están los riesgos de fallas?
• ¿Cómo proporcionará confiabilidad?
• ¿Cómo proporcionará seguridad?

Entonces, en cierto sentido, la arquitectura técnica es como la arquitectura de un edificio. Es el diseño, o el plan. Muestra lo que se necesita para las distintas partes, cómo se mantienen juntas y, lo más importante, por qué .

(Por cierto, me han explicado una curva de crecimiento similar para arquitectos, desde la arquitectura de una familia de aplicaciones relacionadas o un conjunto de características muy complejas, a la configuración de la dirección técnica de un grupo, a la toma de decisiones técnicas estratégicas para toda una organización.)

Dicho esto, creo que la mayoría de los ingenieros en todos los niveles también tienen que hacer un poco de "arquitectura". No es una línea brillante. Suena como si primero se enfocara en el Big Picture y no se atascara en los detalles de la implementación, estará más en línea con lo que está buscando. Por cierto, la capacidad de ver el panorama general y los pequeños detalles es un gran activo en esta industria, por lo que suena como una gran oportunidad.

... Aquí hay una analogía. Digamos que te piden que crees una caja negra mágica. Como ingeniero, se espera que te obsesiones con el funcionamiento interno de la Magic Black Box. Pero como arquitecto, su enfoque es diferente. Puede mirar por curiosidad dentro de la caja, pero se espera que se obsesione con todo alrededor de todas las Cajas Negras Mágicas

Similar a esa analogía, puede pensar que el rol de la arquitectura es ver el sistema completo como la caja mágica. Entonces, si toma una Gigantic Glass Box y coloca a los clientes, las aplicaciones del cliente, el firewall, el nivel de servicio, la base de datos e incluso los devops de los chicos, entonces, como arquitecto, debe obsesionarse con la forma de hacer esa enorme caja de sistema. funciona bien .

La diferencia exacta entre "diseño" y "arquitectura" es un poco subjetiva y existe cierta superposición. Sin embargo, esta es la diferencia como la entiendo:

Arquitectura examina conceptos de alto nivel. ¿Quiénes son los actores en el sistema? ¿Cuáles son los objetos principales y cuáles son responsables de qué? Cuando pienso en arquitectura, pienso en Visio, no en código.

Por ejemplo, un sistema de eventos puede tener un administrador de eventos que acepta eventos entrantes y los envía a los controladores de eventos. La idea de subprocesos, v asíncrono y otros conceptos de nivel inferior no entran en juego aquí. MVC es otro ejemplo: los detalles específicos no se especifican en el alto nivel de cómo interactúan las tres partes, solo que hay tres preocupaciones separadas que se manejan en paquetes de códigos separados.

Diseño implica creación de prototipos, esbozo de interfaces de código, esqueletos de código, etc. Se encuentra entre la arquitectura abstracta y el trabajo de bajo nivel "code monkey".

En un marco de eventos, el diseño podría decir "un evento usa esta interfaz" y "hay un grupo de subprocesos que el administrador de eventos usa para enviar eventos a los trabajadores". Un diseño para MVC podría ser "usar Hibernate para el modelo, Spring para el controlador y GWT para la vista".

Cuando trabajo en el diseño, tengo un bosquejo de interfaces y esqueletos de código, luego entrego los resultados a los programadores. A veces soy ese programador. Pero son dos fases separadas, y ambas existen más hacia lo concreto que hacia la arquitectura.

Ponerse el sombrero de la arquitectura significa despejar la mente del código y pensar los objetos en una pizarra. Piense en objetos, paquetes, marcos y el flujo de mensajes entre ellos. Si está pensando en una sola línea de código, lo está haciendo mal. No se enrede en algo como "oh, ese mensaje podría ser una cadena, o usar SOAP, o lo que sea". En este nivel, el hecho de que la comunicación esté ocurriendo es suficiente. Los detalles son irrelevantes.

  

Si puedo agregar cualquier cosa aquí, es lo siguiente: no pienses en el código . En absoluto.

No pienses cómo escribirás el código para lograr algo, pero piensa en lo que mejor método sería para lograrlo . Su descripción de lo que debe hacer debe ser independiente del lenguaje , por lo que hablará de patrones de diseño, que son un "lenguaje" común entre usuarios de diferentes lenguajes de programación, para analizar cómo proceder.

Para su caso de uso específico, más preguntas arquitectónicas en mi opinión serían las siguientes:

• ¿Por qué estás usando MVC? ¿Es todo lo que sabes? ¿Hay mejores patrones para usar? ¿Por qué?
• ¿Qué marco usarás y por qué ?
• ¿Cómo escalarás? No es código sabio, porque eso no importa todavía. ¿Cuáles serán las condiciones para escalar horizontalmente? ¿Qué servicio (AWS) utilizará para hacer esto?
• ¿Cómo se realizará la autenticación? No en lo que respecta al código: ¿generará un token único y aleatorio en cada solicitud y lo comprobará con el token esperado? No pienses cómo harás esto en código. Piense acerca de por qué está haciendo esto, porque esto se puede hacer en prácticamente cualquier idioma web.

Básicamente, no hables del código. Incluso si no sabes cómo hacer algo, cuando hay un testamento, hay una manera . Piense más acerca de cómo encajarán mejor las piezas del rompecabezas, antes de preocuparse por realmente armarlas.

Piense en todas las operaciones (es decir, casos de uso) que su sistema puede realizar. Para cada operación, documente lo que sucede en términos de su dominio empresarial para cada operación. Solo debe hablar en términos de su dominio de problemas y no describir ningún detalle de implementación. Dibuja un bloque grande y llámalo Sistema. La combinación de este "bloque grande" y las descripciones de operación es la arquitectura del sistema de más alto nivel.

Si bien esta arquitectura de alto nivel proporciona un punto de partida decente, realmente no tiene mucho valor cuando se construye un sistema real. Debe reducir un nivel de detalle para convertir esto en una arquitectura útil.

Por lo tanto, sigue la misma idea general que el enfoque de "bloque grande", solo que comienza a agregar "sub-bloques" que son necesarios para llevar a cabo cada operación. Estos "sub-bloques" son frecuentemente llamados clases de dominio o módulos. Estos se identifican fácilmente mediante el uso de las descripciones de sus operaciones (desde el enfoque de bloque grande) y dibujando diagramas de secuencia. Se denominan clases de dominio porque no pretenden ser clases "reales", sino que están destinadas a describir su sistema en términos del dominio del problema de su sistema.

El resultado final de crear todo el diagrama de secuencia e identificar todos los "sub-bloques" es que ahora tiene una lista de clases de dominio y sus listas de operaciones. Esto generalmente termina dando como resultado una arquitectura de software bastante utilizable, donde cada uno de los "sub-bloques" / módulos podría ser distribuido a diferentes desarrolladores para diseñar e implementar.

Por supuesto, si lo deja como está, entonces sus diseñadores tendrán mucha interacción entre sí para definir las interfaces entre los módulos. Por lo tanto, el arquitecto también puede decidir sobre los mecanismos de interfaz específicos y los tipos de datos que se utilizarán entre los módulos.

Además, algunos "sub-bloques" seguirán siendo muy complicados bajo el capó. Por lo tanto, otra iteración del enfoque de "sub-bloque" puede ser necesaria pero solo esta vez en uno de los módulos recién identificados.

Finalmente, puede haber algunos patrones / limitaciones específicos entre las interfaces a las que el arquitecto desea que se adhiera el sistema (por ejemplo, devoluciones de llamadas de eventos frente a llamadas de método directo), por lo que esas decisiones deberían tratarse en el diseño arquitectónico. Además, puede haber módulos "comunes" que el arquitecto quiere que todos usen.

Como desarrollador, probablemente esté acostumbrado a proporcionar soluciones. Esa es una muy buena manera de pensar, pero puede obstaculizarte cuando se trata de pensar en arquitectura.

Encuentro que es útil describir primero el problema que intentas resolver. ¿Qué son los requerimientos? ¿Cuáles son las restricciones? ¿Puede hablar con las partes interesadas para averiguar estos requisitos?

Podría ayudar si también puede describir sus propios objetivos de diseño. ¿Necesita su solución escalar o es suficiente un diseño para un solo usuario? ¿Cuánto tiempo debe permanecer su solución válida? ¿Es una solución de una sola vez o una solución de infraestructura a largo plazo? Quizás también sea importante: ¿Cuáles son los límites aceptados de su arquitectura?

Y como esta es una experiencia de aprendizaje, no tengas miedo de hacer preguntas, incluso si son tontas.