Arquitectura DDD(Domain Driven Design)
Cuando referimos DDD (Domain Driven Design), estamos hablando de un conjunto de patrones principios y prácticas que nos ayudan a entender, resolver y diseñar las mejores soluciones a los problemas del negocio (Dominio), siempre dentro del ámbito del diseño de sistemas orientados a objetos e igualmente, representa la terminología y los conceptos clave del dominio del problema.
Por tanto, DDD identifica las relaciones entre las entidades incluidas dentro del ámbito del dominio del problema, identifica sus atributos y proporciona una visión estructural del dominio. Donde Domain driven design es un enfoque para el desarrollo de software definido por Eric Evans en su libro Domain-driven design: Tackling Complexity in the Heart of Software, que se centra en un modelo completo, expresivo y en constante evolución para resolver problemas del dominio de una forma semántica.
Las entidades son objetos del modelo que se caracterizan por tener identidad en el sistema, los atributos que contienen no son su principal característica. Representan conceptos con una identidad que se mantienen en el tiempo, y que con frecuencia también se mantienen bajo distintas representaciones de la entidad. Deben poder ser distinguidas de otros objetos aunque tengan los mismos atributos. Tienen que poder ser consideradas iguales a otros objetos aún cuando sus atributos difieren.
La identidad tiene que ser declarada de tal manera que podemos rastrear la entidad de manera eficaz. Los atributos, responsabilidades y relaciones deben ser definidas en relación a la identidad que representa la entidad más que en los atributos que la componen.
Es decir que para identificar y distinguir distintos objetos a lo largo de su ciclo de vida hace que la complejidad para manejarlos y diseñarlos sea bastante mayor que la de los que no la necesitan. Por este motivo debemos usar entidades únicamente para objetos que realmente lo requieran, lo cual tiene dos ventajas importantes. Por un lado, no incluiremos complejidad innecesaria en objetos que no requieran ser identificados, por otro lado al reducir el número de entidades en el sistema seremos capaces de identificarlas rápidamente.
Sobre los value object, estos representan elementos del modelo que se describen por el QUÉ son, y no por QUIÉN o CUÁL son. Por tanto, un objeto Color representado por su composición RGB(Red, Green, Blue). Si tuviéramos dos objetos representando el mismo color podríamos usar cualquiera de ellos, ya que nos interesa qué color es por sus atributos, no por cuál instancia estamos usando. Otros ejemplos de value objects podrían ser String o Integer, ya que no nos importa que ¨C¨ o que ¨3¨ estamos usando. Aunque estos ejemplos son simples los value objects no tienen porque serlo.
