1. ¿Cuál es la estructura?
En términos generales, la arquitectura es una estructura combinada, que incluye la arquitectura del producto y la arquitectura del sistema. Una buena arquitectura puede hacer que los productos y los sistemas se presenten mejor, se iteren y mantengan mejor. Se desarrolla una buena arquitectura y se refactoriza un buen código.
A menudo escuchamos sustantivos como plataforma intermedia, plataforma, sistema y aplicación.¿Cuál es la relación entre ellos antes?
1) Aplicación: Es la granularidad más pequeña y se utiliza para realizar las funciones del sistema empresarial. Por ejemplo, los microservicios son populares ahora y las aplicaciones que implementan un sistema comercial generalmente incluyen: aplicaciones web y aplicaciones de servicio.
2) Sistema: Los sistemas mencionados aquí son todos sistemas de negocios. Generalmente, un sistema de negocios es al menos un producto comercial completo. Como el sistema de abastecimiento, el sistema de licitación, etc.
3) Plataforma: Está compuesta por múltiples sistemas de negocios. Las capacidades de la plataforma son más ricas que las de un solo sistema de negocios. La plataforma proporciona capacidades de negocios relativamente completas en un campo determinado. Por ejemplo, la plataforma de adquisiciones se compone de sistemas comerciales como abastecimiento y licitación. La plataforma es una reutilización funcional y, por lo general, solo admite un único escenario, como una plataforma de adquisiciones de grandes empresas, que solo admite el escenario de adquisiciones de grandes empresas.
4) Plataforma intermedia: sobre la base de la plataforma, se admiten múltiples escenarios a través de puntos de extensión, que es la reutilización comercial. El centro de adquisiciones puede respaldar la adquisición de grandes empresas, pequeñas y medianas empresas e individuos.
Cada nivel tiene su propia arquitectura (arquitectura de plataforma, arquitectura de sistema empresarial, arquitectura de aplicación) y también se enfoca en cosas diferentes. La arquitectura de la plataforma y la arquitectura del sistema prestan más atención a: la división de los límites de responsabilidad, los métodos de implementación y la aplicación de nuevas tecnologías (acceso a la nube, microservicios, etc.). La arquitectura de la aplicación se centra más en las capas y el diseño de la propia aplicación. Por ejemplo, la arquitectura en capas y el diseño basado en dominios DDD son más populares ahora , y la arquitectura de aplicaciones será el tema central de este artículo.
2. División de responsabilidades
La división de los límites del sistema es crucial para la arquitectura empresarial.El principio general es: división según responsabilidades. Cuando una responsabilidad no sabe a qué dominio está asignada, se puede asignar un dominio intermediario.
Al analizar los casos de uso, los modelos en el mismo dominio deben interactuar mucho, y los modelos de dominios cruzados rara vez deben interactuar. Si encuentra que los modelos de dominios cruzados interactúan mucho, es probable que haya un problema con la división de responsabilidades de dominio
3. Diseño basado en dominios y sus componentes principales
Introducción al diseño dirigido por dominios
¿Qué es controlado por dominio? El diseño basado en dominios es una idea que guía el diseño y el desarrollo de sistemas. Requiere que prestemos atención al conocimiento del dominio comercial, comprendamos el conocimiento del dominio y estemos orientados al dominio y al modelo. En lugar de un diseño orientado a la tecnología y orientado a los datos. A través de la comunicación continua con expertos en dominios comerciales, la comprensión profunda del conocimiento del dominio, la iteración continua del diseño del sistema y luego la presentación de un mejor modelo de dominio. Un modelo de dominio valioso no debe aparecer de inmediato, sino que debe obtenerse después de una comprensión profunda del conocimiento del dominio.
¿Por qué es necesario el Diseño de Dominio? La complejidad de un sistema de software a menudo no proviene de la implementación técnica en sí, sino del negocio en sí mismo, los procesos comerciales complejos y la evolución.
El modelo de dominio debe ser entendido por expertos tanto técnicos como comerciales. Si los expertos de dominio no pueden entender el modelo de dominio, entonces el modelo debe diseñarse incorrectamente. El modelado de dominio no se trata solo de crear entidades, sino que también incluye objetos de valor, servicios de dominio y patrones de implementación. El diseño y la implementación deben estar vinculados, y el diseño y la implementación no deben separarse. Cuando vea el diseño del dominio, debe conocer el modo de implementación del sistema. De lo contrario, los implementadores no entenderán la intención del diseño del dominio, cuanto más se desvíe la implementación del sistema del diseño del dominio, y la integridad de los datos del modelo del dominio será difícil de garantizar. Todo el diseño del dominio no tendrá sentido.
El modelo de dominio no es solo una abstracción de los conceptos básicos del dominio, sino que también puede guiar el desarrollo y la implementación del software. El diseño orientado a objetos es el paradigma de modelado utilizado para la mayoría de los modelos de dominio.
Los componentes principales del dominio incluyen objetos de dominio y administración del ciclo de vida de objetos de dominio.Los objetos de dominio incluyen: entidades, objetos de valor y servicios de dominio. La gestión del ciclo de vida de los objetos de dominio incluye: fábrica, repositorio, agregación. Tanto los objetos de dominio como la administración del ciclo de vida de los objetos de dominio son activos centrales de la capa de dominio .
1) Entidad: una entidad puede existir de forma independiente y ser significativa en la interacción comercial, y requiere la existencia de un signo único, y el signo único tiene un significado comercial real. Por ejemplo, al comprar en línea, aunque el contenido de los paquetes enviados sea el mismo, son dos paquetes diferentes.
2) Objetos de valor: generalmente solo se preocupan por el contenido, no se preocupan por la necesidad de un identificador único y usan la agregación como un atributo adicional de la entidad. Por ejemplo, cuando una persona dibuja con un pincel, solo le importa el color, el grosor y otras características del pincel, no de qué pincel es. En resumen, en la escena, si el contenido es exactamente el mismo, se puede considerar como el mismo objeto, es un objeto de valor, de lo contrario es una entidad.
3) Servicio de dominio: A veces habrá algunas operaciones especiales en el dominio, que no pertenecen a ninguna entidad u objeto de valor. En este momento, se pueden usar los servicios de dominio. En este momento, los servicios de dominio son la mejor manera de representar los conceptos de dominio. Los parámetros y los valores de retorno de los servicios de dominio deben ser modelos en el dominio, y los servicios deben ser sin estado.
4) Agregación: la agregación consiste en tomar una entidad como raíz agregada y agregar otros objetos de valor como atributos. La raíz agregada debe ser la unidad más pequeña de modificación/consulta y se debe modificar/consultar con la raíz agregada como unidad. La agregación generalmente se refiere a la relación entre entidades y objetos de valor, y la asociación generalmente se refiere a la relación entre entidades.
5) Fábrica: La responsabilidad principal de la fábrica es crear objetos y reconstruir objetos (reconstruir los datos consultados desde el medio de almacenamiento en objetos de dominio). La creación de objetos complejos pertenece a la capa de dominio, no tiene que realizarse a través del objeto en sí, sino que se puede crear a través de la fábrica. Las fábricas generalmente se usan para crear tipos de objetos complejos que requieren generalización, y los objetos modelo simples se pueden crear directamente a través de constructores.
6) Repositorio: La principal responsabilidad es la conversión mutua entre objetos y almacenamiento, pudiendo abstraerse adecuadamente el tipo, no es necesario que cada modelo corresponda a un repositorio.
Mejores prácticas de capas de arquitectura de aplicaciones DDD
1) Arquitectura de aplicaciones en capas
2) Capacidad comercial
A través del ensamblaje de capacidades en diferentes campos (posiblemente entre organizaciones y departamentos), se pueden sintetizar ciertas capacidades comerciales y el acceso rápido a través de la configuración + personalización puede acelerar la iteración comercial.
4. Ideología rectora del diseño impulsado por el dominio
1) En la capa de dominio, los conceptos del dominio deben usarse para expresar la lógica comercial, y toda la lógica del dominio central se implementa en función de los componentes del dominio. En lugar de confiar directamente en implementaciones externas y no exponer interfaces irrelevantes al mundo exterior, la capa de dominio debería ser el objeto de protección clave.
2) La capa de repositorio generalmente no participa en el control de transacciones.
3) Siempre preste atención al diseño y las responsabilidades del modelo de dominio, adhiérase al principio SOLID de diseño orientado a objetos y no use objetos de dominio solo como contenedores de datos.
4) Intente atravesar la base de datos a través de la raíz agregada para encontrar el objeto de valor asociado en lugar de atravesar directamente el objeto de valor. Si realmente necesita omitir la entidad y atravesar directamente el objeto de valor, entonces debe considerar si el diseño del modelo no es razonable y si es necesario diseñar el objeto de valor como una entidad.
5) Todo el diseño debe ser de bajo acoplamiento y alta cohesión, incluido el diseño y la división del paquete.
6) El diseño de software siempre debe luchar contra la complejidad y dejar el diseño complejo donde realmente se necesita. El modelado de dominio comienza con la simplificación de asociaciones . La asociación entre modelos debe ser lo menos compleja posible, los que pueden asociarse uno a muchos no deben diseñarse como asociaciones muchos a muchos, los que pueden asociarse uno a uno no deben diseñarse asociaciones uno a muchos y los que pueden asociarse unidireccional no deben ser bidireccionales. Cuando la simplificación no sea posible, considere si puede agregar algunas condiciones apropiadas y realistas que puedan reducir la complejidad de la asociación. Cuanto más compleja sea la asociación, más difícil será garantizar la consistencia de los datos, más difícil será garantizar la estabilidad del sistema y aumentará la complejidad de la implementación del sistema. Si la relación se puede simplificar adecuadamente, también refleja una comprensión profunda del conocimiento del dominio. Las asociaciones restringidas pueden transmitir más conocimiento y son más prácticas.Simplificar y restringir cuidadosamente las asociaciones de modelos es la única forma de lograr un diseño dirigido por el dominio.
7) Diseñe la estructura de almacenamiento de datos de acuerdo con las necesidades de las entidades y los objetos de valor. Generalmente, la información relacionada con el modelo de dominio 1 a 1 se puede almacenar en una tabla de datos, a menos que los campos grandes se separen en tablas diferentes. Los datos de 1 a muchos solo se pueden separar en diferentes tablas. El diseño de la base de datos debe cumplir con: hacer que nuestra consulta y actualización de datos sea más eficiente y garantizar la integridad de los datos de manera más segura.
8) Además de acceder a los objetos asociados en el agregado a través de la raíz agregada, no se permite acceder a otros objetos en el agregado de ninguna otra manera.