Metodología de Modelado de Dominio
Ley de Arquitectura Empresarial
Modelo de negocio por componentes de CBM
Los verticales en la figura son en realidad subdominios y contextos de límite, y los horizontales pueden ser algunas capas de políticas, capas de control y capas de ejecución, y hay elementos uno por uno en ellos. Estos contenidos pueden corresponder a cada uno en nuestro diseño de dominio. Agregación, entonces hay muchas agregaciones y muchos subsistemas.
Si la agregación es demasiado detallada, no podemos escribirla con tanta precisión, entonces puede ser microservicios y módulos uno por uno.
Diseño de Arquitectura Orientada a Servicios
Modelo de arquitectura orientada a servicios SOA
SOA se basa en el bus. En el bus, se deben completar las colas de mensajes asincrónicos, las llamadas API sincrónicas, el registro del servicio, etc.
Lo anterior también se puede conectar, como servicios de aplicaciones basados en procesos, interfaces de terceros, contenido interactivo, gestión de información, módulos de seguridad, funciones de modelado, etc., todas las funciones están conectadas en el bus. Esta situación se basa en el bus como piedra angular, y luego enchufar y desenchufar varios contenidos. Hablando en términos relativos, podemos dividir el negocio libremente y luego conectarnos a este componente para comunicarnos y comunicarnos entre nosotros. Basados en el mismo conjunto de estándares y el mismo conjunto de protocolos de comunicación, desarrollamos toda nuestra arquitectura de TI.
Ya sea CBM o SOA, estos dos tipos se desarrollaron hace cinco años y están un poco desactualizados.
Entonces, ¿hay algo más nuevo? Hay tres más nuevos.
análisis de casos de uso
En pocas palabras, es usar el lenguaje UML para desmantelar todas las necesidades específicas de los clientes. Se puede dibujar con el modelo de cubo del pensamiento del arquitecto, o puede ser como la imagen de arriba, la parte superior es el modelo de componentes, y la esquina inferior izquierda es un análisis de caso de uso estándar, la esquina inferior derecha es el modelo cuatro más uno y así sucesivamente.
Hay muchas, muchas variantes diferentes del lenguaje UML y muchos modelos de diseño.
Pero los tres modelos anteriores están básicamente relacionados con el dominio, pero no es un modelo de dominio propietario. Hay dos modelos en la parte posterior. Solo nacen para el dominio, y también son modelos relativamente modernos. Echemos un vistazo juntos. .
método de modelado de cuatro colores
Todavía recuerdo un juego que jugaba cuando era niño, un estudiante escribió una nota y luego dividió el trabajo, algunos estudiantes escribieron quién, algunos estudiantes escribieron dónde, algunos estudiantes escribieron a qué hora, algunos estudiantes escribieron qué hacer y luego combinándolos Levántate y cuenta una pequeña historia.
El método de modelado de cuatro colores es similar a este juego.
- Quién, dónde: objetos PPT (Fiesta/Lugar/Cosa)
- Qué identidad: rol (Role) objeto
- cómo: descripción: (Descripción) objeto
- Qué hacer: Objetos Momento-Intervalo
Como se muestra en la imagen de arriba, únase a nosotros para comprar cosas en línea, hacer un pedido, luego habrá pedidos, registros bancarios en línea, talones de paquetes, etc. Estos registros son comportamientos que ocurrieron dentro de un período de tiempo, este es el primer rojo .
Luego hacemos un seguimiento con quién y dónde. Por ejemplo, la cuenta del usuario es "quién", el objeto del pedido generado son libros y los empleados están mirando los registros de promoción. "Dónde" es la ubicación geográfica y la información es verde Contenido.
El siguiente paso es amarillo. El color amarillo representa el rol. Por ejemplo, el rol es el director de marketing. Este empleado es el director de marketing, por lo que desea verificar los registros de promoción de toda la empresa y, al mismo tiempo, está el distribuidor, por lo que quiere enviar un paquete.
El último paso es azul, el azul es una descripción y el libro tiene una descripción.
Conectar estos cuatro en serie es el método de análisis de cuatro colores .
Una vez que una escena muy compleja se convierte en una descripción simple, básicamente aparecerán entidades y objetos de valor. Generalmente, el verde y el rojo serán descritos por entidades o raíces agregadas. Se puede considerar que el amarillo y el azul usan objetos de valor, especialmente el azul. Colores son básicamente objetos de valor, y el amarillo también puede tener una consideración entre objetos de valor y entidades.
Tal método es relativamente simple, por lo que es más adecuado para comunicarse con el personal comercial.Usar ese conjunto de lenguaje para describir el negocio claramente,
Tormenta de eventos
¿Qué tipo de metodología es esta? ¿Qué tipo de problema está tratando de resolver?
De hecho, si lo pensamos detenidamente, si desea dividir todo el campo y modelarlo bien, en realidad hay muchos problemas, como:
- Arquitectura evolutiva y desarrollo iterativo
- Compatibilidad directa y dividida de microservicios
- Cómo comunicarse con el personal de ventas de productos
- ¿Hay alguna manera de completar la división de microservicios al beber té y chatear?
Entonces event storm es una buena solución a estos problemas, tiene las siguientes características:
- no hay necesidad de hacer un dibujo
- Sin Visio, Word y PPT
- Prepara una docena de notas adhesivas.
- Todo el proceso de chatter y juegos de pegatinas completa la división de los módulos de microservicio
Tomemos como ejemplo un sistema de gestión de proyectos ágil: como
se muestra en la figura anterior, este es el primer gran paso en la división de microservicios y, finalmente, dividido en barras verticales, cada barra vertical es en realidad un microservicio.
Por supuesto, hay un segundo gran paso:
resolver la relación entre estos servicios, ¿debería ser una llamada síncrona? ¿O mensajes asíncronos? ¿Qué métodos deben proporcionarse para la comunicación? ¿Qué variables miembro se deben proporcionar en cada agregado y entidad? Después de hablar de todo esto claramente, la arquitectura se puede diseñar fácilmente para diagramas de clase o diagramas ER.
Durante todo el proceso de tormenta de incidentes, hasta que se dividan todos los servicios y se resuelva la relación entre todos los servicios, este proceso no requiere hacer dibujos, solo se necesitan calcomanías, pero aún se requiere TI para los códigos de diseño posteriores y la implementación del sistema. los diagramas y los diagramas de arquitectura, estos diagramas no tienen nada que ver con nuestros gerentes de producto y partes comerciales, pero todo el proceso involucra la participación de gerentes de producto y partes comerciales sin ningún medio de TI. Este es el punto culminante de nuestra tormenta de eventos.