Esta publicación fue editada por última vez por Summer el 27-9-2017 a las 15:32
Este artículo es un relato corto que imita preguntas y respuestas, y el autor utiliza un estilo humorístico para analizar brevemente el trabajo que hacen los arquitectos: quiero ser arquitecto de software. Es una gran opción para desarrolladores de software jóvenes. Quiero liderar el equipo y tomar decisiones importantes sobre bases de datos y frameworks, servidores web, etc. Ah, entonces no quieres ser arquitecto de software en absoluto. Por supuesto que quería ser quien tomara decisiones importantes. Está bien, pero no incluyes decisiones importantes en tu lista, que son decisiones irrelevantes. ¿Qué quieres decir? ¿Estás diciendo que las bases de datos no son decisiones importantes, sabes cuánto gastamos en ellas? Quizá cuesta demasiado. Sin embargo, las bases de datos no son una de las decisiones importantes. ¿Cómo puedes decir eso? La base de datos es el núcleo del sistema, donde todos los datos se sistematizan, clasifican, indexan y acceden. Sin una base de datos, no habría sistema. La base de datos es simplemente un dispositivo de IO que proporciona algunas herramientas útiles para clasificación, consulta e informes de información, pero estas son solo funciones auxiliares de la arquitectura del sistema. ¿Ayuda? Esto es indignante. Exacto, es auxiliar. Las reglas de negocio del sistema pueden aprovechar algunas de estas herramientas, pero esas herramientas no son inherentes a las reglas de negocio correspondientes. Si es necesario, puedes reemplazar las existentes por herramientas diferentes; Y las reglas de negocio no cambiarán. Bueno, sí, pero tuvo que ser recodificado, porque estas herramientas se usaban en la base de datos original. Ese es tu problema. ¿Qué quieres decir? Tu problema es que crees que las reglas de negocio dependen de herramientas de bases de datos, pero no es así. O al menos, no debería ser así hasta que se proporcione una buena arquitectura. Es una locura. ¿Cómo creas reglas de negocio que no usan esas herramientas? No digo que no usen herramientas de bases de datos, pero no dependen de ellas. Las reglas de negocio no necesitan saber qué base de datos estás usando. Entonces, ¿cómo consigues reglas de negocio sin saber qué herramientas usar? Invertir las dependencias para que la base de datos dependa de las reglas de negocio. Asegúrate de que las reglas de negocio no dependan de la base de datos. Estás diciendo tonterías. Al contrario, estoy utilizando el lenguaje de la arquitectura de software. Este es el principio de inversión de dependencias: los estándares de bajo nivel deben basarse en estándares de alto nivel. ¡Tonterías! Criterios de alto nivel (asumiendo que se refieren a reglas de negocio) Llamar criterios de bajo nivel (suponiendo que se refieren a bases de datos). Por lo tanto, el criterio de alto nivel se basará en el criterio de bajo nivel según el principio de que el llamante depende del destinatario. ¡Todo el mundo lo sabe! Esto es cierto en tiempo real. Pero al compilar, lo que queremos es inversión de dependencias. El código fuente de las directrices de alto nivel no debe mencionar el código fuente de las directrices de bajo nivel. ¡Vamos! ¿Cómo puedes hacer una llamada sin mencionarlo? Por supuesto, ningún problema. Eso es lo que implica el orientado a objetos. La orientación a objetos consiste en la creación de modelos en el mundo real, combinando datos, funcionalidad y objetos cohesivos. Se trata de organizar el código en una estructura intuitiva. ¿Eso dicen? Como todos sabemos, esta es la verdad obvia. Sí, lo es, sin embargo, al usar directrices orientadas a objetos, es efectivamente posible invocar sin mencionarlo. Bueno, ¿cómo se hace eso? En el diseño orientado a objetos, los objetos se envían mensajes entre sí. Así es, por supuesto. Cuando un remitente envía un mensaje, no sabe qué tipo de destinatario es. Depende del lenguaje que se utilice. En Java, el emisor conoce al menos el tipo base del receptor. En Ruby, al menos el emisor sabe que el receptor es capaz de manejar los mensajes recibidos. Así es. En cualquier caso, sin embargo, el emisor no conoce el tipo específico de receptor. Así es, bueno, lo es. Por lo tanto, un emisor puede diseñar un receptor para que realice una función sin mencionar el tipo específico de receptor. Eso es, eso es. Entiendo. Sin embargo, el emisor sigue dependiendo del receptor. Esto es cierto en tiempo real. Sin embargo, es diferente cuando se compila. El código fuente del emisor no menciona ni depende del código fuente del receptor. De hecho, el código fuente del receptor depende del código fuente del emisor. ¡No es posible! El remitente sigue dependiendo de la clase que envíe. Quizá a partir de algún código fuente sea más claro. El siguiente párrafo está escrito en Java. Primero está el remitente: remitente del paquete; emisor de clase pública { receptor receptor privado; Emisor público (Receptor r) { receptor = r; } vacío público doAlgo () { receptor.receiveThis (); } interfaz pública Receptor { void receiveThis (); } }Aquí está el receptor: receptor de paquete; importar remitente. Remitente; la clase pública SpecificReceiver implementa Sender.Receiver { public void receiveThis () { //hacer algo interesante. } }Nota: El receptor depende del remitente, SpecificReceiver depende del remitente, y no hay información relacionada con el receptor en el emisor. Sí, pero mientes, pones la interfaz del receptor en la clase de emisor. Empiezas a entender. ¿Qué sabes? Por supuesto, es el principio de la arquitectura. El emisor tiene la interfaz que el receptor debe implementar. Si eso significa que tengo que usar clases anidadas, entonces ...... Las clases anidadas son solo uno de los medios para un fin, hay otras formas. Espera un momento. ¿Qué tiene que ver esto con las bases de datos? Empezamos a hablar de bases de datos. Veamos un poco más el código. La primera es una regla de negocio sencilla: paquetes de Reglas de negocios; importar entidades. Algo; clase pública BusinessRule { privado BusinessRuleGateway gateway; BusinessRule pública (BusinessRuleGateway gateway) { this.gateway = gateway; } empty public void execute (String id) { gateway.startTransaction (); Algo cosa = gateway.getAlgo (id); thing.makeChanges (); gateway.saveSomething (cosa); gateway.finTransacción (); } }Las reglas de negocio no tienen mucho peso. Este es solo un ejemplo. Podría haber más clases que implementen muchas reglas de negocio diferentes. Vale, ¿qué es exactamente Gateway? Proporciona todos los métodos de acceso a los datos mediante reglas de negocio. Implementa la siguiente manera: paquetes de Reglas de negocios; importar entidades. Algo; interfaz pública BusinessRuleGateway { Something getSomething (String id); void startTransaction (); void saveAlgo (algo de algo); void endTransaction (); }Nota: Esto está en las reglas de negocio. Vale, ¿qué es la clase de algo? Representa un objeto de negocio sencillo. Lo pongo en entidades. entidades de empaquetamiento; clase pública Algo { public void makeChanges () { //... } }En última instancia, la implementación de BusinessRuleGateway, esta clase conoce la base de datos real: base de datos de paquetes; importar BusinessRules.BusinessRuleGateway; importar entidades. Algo; la clase pública MySqlBusinessRuleGateway implementa BusinessRuleGateway { public Something getSomething (String id) { // usa MySQL para obtener algo. } empty público iniciaTransacción () { // iniciar transacción MySql } empty public void saveAlgo (Algo thing) { // guardar algo en MySQL } public void finTransacción () { // fin Transacción MySQL } }Además, hay que tener en cuenta que las reglas de negocio llaman a la base de datos en tiempo de ejecución; Sin embargo, en momento de compilación, la base de datos implica y depende de las reglas de negocio. Bueno, creo que lo entiendo. Solo estás usando polimorfismo para ocultar que la base de datos está implementada a las reglas de negocio. Sin embargo, sigue siendo necesaria una interfaz para proporcionar todas las herramientas de base de datos a las reglas de negocio. No, para nada. No hemos intentado proporcionar herramientas de base de datos a las reglas de negocio. En su lugar, utilizan reglas de negocio para crear interfaces según lo que necesitan. Implementar estas interfaces te permite llamar a las herramientas adecuadas. Sí, pero si necesitas usar todas las herramientas para todas las reglas de negocio, simplemente pon la herramienta en la interfaz del gateway. Ah, creo que aún no lo entiendes. ¿Entender qué? Esto ya está claro. Cada regla de negocio define solo una interfaz para las herramientas de acceso a datos que necesita. Espera un momento, ¿qué dices? Este es el Principio de Segregación de Interfaces. Cada clase de reglas de negocio utiliza solo ciertas facilidades de la base de datos. Por lo tanto, las interfaces proporcionadas por cada regla de negocio solo pueden acceder a las instalaciones correspondientes. Sin embargo, esto significa que existen muchas interfaces y muchas pequeñas clases de implementación que llaman a otras clases de bases de datos. Genial, ya empiezas a entender. Pero es demasiado desordenado y una pérdida de tiempo. ¿Por qué hacer esto? Esto está organizado y ahorra tiempo. Venga, consigue mucho código por el simple hecho de programar. Por el contrario, las decisiones irrelevantes pueden retrasarse por decisiones arquitectónicas importantes. ¿Qué significa eso? Recuerdo que al principio dijiste que querías ser arquitecto de software, ¿no? Quieres tomar todas las decisiones que realmente importan. Sí, eso pensé. Quieres tomar decisiones sobre bases de datos, servidores web y frameworks, ¿verdad? Sí, dices que nada de eso importa. Solo contenido irrelevante. Así es. Eso es todo. Las decisiones importantes que toman los arquitectos de software son aquellas que te permiten tomar decisiones sobre bases de datos, servidores web y frameworks. ¡Pero primero tienes que decidir cuáles son los que se tienen! No, no funciona. De hecho, estos pueden decidirse más adelante en el ciclo de desarrollo, cuando la información es más abundante. Es un desastre si los arquitectos identifican los marcos de mano solo para descubrir que no proporcionan el rendimiento requerido o introducen restricciones intolerables. Solo cuando el arquitecto decide posponer la decisión tomará una decisión cuando la información sea suficiente; Los equipos que no utilizan dispositivos y frameworks de IO lentos y que requieren muchos recursos pueden crear entornos de prueba rápidos y ligeros a discreción de los arquitectos. Solo sus arquitectos se preocupan por lo que realmente importa y retrasan a quienes no, y un equipo así es el afortunado. Tonterías, no entiendo nada a qué te refieres. Bueno, echa un buen vistazo a este artículo, si no, tendrás que esperar otros 10 años para entenderlo.
| 
Publicado en 27/9/2017 15:29:46
|
|
|
Publicado en 28/9/2017 15:00:37
|
Propietario|
Publicado en 29/9/2017 8:34:23
|
Publicado en 27/11/2018 11:12:17
|
