Este artículo proviene de un motor de traducción automática.

Nota del editor

Arquitectura y agregados

Howard Dierking

Como puede ver en el contenido del artículo, nos está centrado este mes en problemas relacionados con la arquitectura de software.Y esas líneas desea aprovechar las ventajas de nota de este editor para hablar sobre algo que ha empleado alguna vez pensar recientemente, agregados.

Ahora, aquellos que he tenido el felizmente de obtener satisfacer (o aquellos a los estoy relacionados con) pueden asegurar al menos dos cosas acerca de mí.En primer lugar, siempre estoy esperando a hablar sobre el desarrollo de software, arquitectura en particular.En segundo lugar, en tales conversaciones, tienden a hablar louder y más rápido a medida que crece el entusiasmo (esto es amplified agregando alguien como mi buen amigo Glenn bloque a la combinación).Agregados es uno de estos temas de arquitectura que obtienen realmente entusiasmado, por lo que asegúrese de que activar hacia abajo de los altavoces.

Un agregado es un término utilizado principalmente por profesionales de dominio controlado por diseño (DDD) y se define como "un clúster de objetos asociados que se trata como una unidad con el propósito de los cambios de datos.Las referencias externas están restringidas a un miembro de la AGGREGATE, designado como la raíz.Un conjunto de reglas de coherencia se aplica dentro de límites 'S el AGGREGATE."

Ahora me permite diga que no soy sólo un partidario de esta manera de descomponer y pensando en un modelo, pero aún más creo que el error al crear límites agregados seguros es uno de los controladores principales detrás de diseños de aplicación spaghetti-similar al que están hopelessly asociados a un esquema de base de datos relacional y demasiado convivencia para evolucionar fácilmente para admitir paradigmas de basada en mensajes, como los utilizados en las arquitecturas de informática de nube.

Sin embargo, en algunos casos, CREO que es posible que se vamos sobre el proceso de definir los límites de agregado de forma sub-optimal.SE piense en la raíz del problema es que, independientemente de si diseñar una base de datos en primer lugar o un objeto modelo en primer lugar, dos representaciones de produzcan una estructura de entidades lógicas específicos, y esta forma de pensar acerca de las abstracciones puede provocar que nos pase por alto posibilidades de simplificación.

Para colocar en un ejemplo, ha estado trabajando en desarrollar un complemento de Microsoft Word para asociar los metadatos de artículo en la manuscript.Los metadatos se administran en SharePoint, que, en términos de la base de datos, cree varios como la topología de estrella de un almacén de datos Kimball de estilo.

Comencé a diseñar la aplicación mediante la creación de un modelo de dominio.El escenario inicial que quería para admitir se examinar la lista de artículos y seleccionar el artículo que se debe asociado el manuscript.Dado que deseaba no sobrecargar mis usuarios con una lista gigante de artículos, agrega exploración al escenario utilizando una jerarquía natural que Magazine contiene los problemas que contienen artículos.¿Suena familiar?

¿Cuál es el problema?Este modelo similar a modelos que todos vimos muchas veces a través de.Sin embargo, es también de este tipo de modelo, donde las personas se ejecutan en problemas para definir los límites de agregado.¿Por qué?Puesto que se basa en estructura en lugar de comportamiento.Para recapitular mi escenario, deseo habilitar mis usuarios para desplazarse por un conjunto de artículos utilizando una jerarquía natural.Por esa lógica, la jerarquía es simplemente una proyección sobre un conjunto de artículos, y cambia el modelo que tengo un agregado artículo claramente definido y único, como se indicó anteriormente.

Ahora, esto es no quiere decir que nunca debe tiene jerarquías tradicionales en los modelos de objetos.En su lugar, ESTOY intentando decir que en lugar de definir agregados al intentar dibujar una línea alrededor de un grupo de clases en un modelo, definir primero los agregados de curso-concreto según el comportamiento, a continuación, permiten que las clases surgen dentro de la definición de agregado.Se evitará la parálisis del análisis de intentar obtener las definiciones de agregado "derecha" e le se inicio fuera en el pie derecho, creación de su sistema basándose en comportamiento a través de la estructura.

Visítenos enmsdn.microsoft.com/Magazine. ¿Las preguntas, comentarios o sugerencias para MSDN Magazine?Para enviarlos al editor:mmeditor@Microsoft.com.

Gracias a los siguientes expertos técnicos de Microsoft por su ayuda con este problema: Boodhoo José de Paul Pablo Castro Constable Ben, Derstadt Jeff, Chuck Esterbrook, Carlos Fabricant, Freeman Steve, Ashok Kamath, Bertrand LeRoy, Pryce NAT, Shetty Ashish, Andrés Díaz, Carlos Tavares Kevin Couto, Dave Fugate, Harry Pierson, Curt Hagenlocher, Lynn Langit, Varsha Mahadevan, Stephen Toub, Mark Lawrence y Henri Socha.