Angel "Java" Lopez : Domain-Driven Design

Arquitectura de capas en Domain-Driven Design

lopez — Sat, 13 Sep 2008 10:29:29 GMT

Esta vez, exploremos los conceptos de arquitectura en capas, tal como lo propuso Eric Evans en su libro clásico Domain-Driven Design, Tackling Complexity in the Heart of Software. En el capítulo cuatro del libro, Evans presenta este diagrama:

Evans Escribe:

En una aplicación de carga y envío de mercadería, para simplemente listar y seleccionar el destino de la carga de una lista de ciudades, debe haber código que (1) dibuje un control en la pantalla, (2) consulte una base de datos para obtener las posibles ciudades, (3) interprete el ingreso de usuario y lo valide, (4) asocie la ciudad seleccionada con la carga, y (5) confirme el cambio en la base de datos. Todo este código es parte del mismo programa, pero sólo una pequeña parte está relacionado con el negocio de envío de cargas.

El propone que el modelo de dominio resida en una capa, la Capa de Dominio. De esta forma, el modelo de dominio es protejido de los detalles técnicos, como la implementación de la persistencia, y los detalles de presentación. Me gusta decir que el dominio es un organismo, qe recibe estímulos, acciones desde el exterior,y reacciona a esos comandos. El dominio debería ejecutarse sin conocimiento detallado del resto de la aplicación. Serialización entre capas físicas, detalles de presentación, y acceso a base de datos, deben estar claramente separados de la implementación del dominio.

Las capas puede ser descriptas como:

UI (User Interface): la más fácil de entender, esta capa es la responsable de mostra información al usuario, y aceptar nuevos datos. Puede ser implementada para web, escritorio gráfico, o cualquier otra tecnología de presentación, presente o futura. Por ejemplo, podría ser una aplicación de voz, que interactúa con el usuario usando un teléfono. La prueba ácida para nuestro diseño es que un cambio radical en la interfaz de usuario debería tener mínimo (o por lo menos, controlado) impacto en el resto del sistema.

Application Layer: está a cargo de coordinar las acciones a ser realizadas en el dominio. No tiene reglas de negocio o conocimiento del dominio. No hay estado del negocio en esta capa. Delega todas las acciones del negocio al propio dominio. Podría coordinar varias acciones (posiblemente, en varios dominios). Preara la infraestructura para que esté lista a trabajar con el dominio en una acción específica (por ejemplo, preparando la transacción que vaya a usar).

Domain Layer: En esta capa reside el corazón del software, según Evans. Las reglas y lógica de negocio residen en esta capa. Estado de entidades de negocio y su conducta es definida y usada aquí. Comunicación con otros sistemas, detalles de persistencia, son delegados en la capa de infraestructura. Evans discute los patrones que él usa en esta capa, como Entities, Value Objects, Services, Repositories y Factories. Exploraremos esos patrones y sus implementaciones en futuros posts.

Infrastructure Layer: Dios y el diablo estan en los detalles, dice el dicho, y también en la capa de infraestructura. La principal responsabilidad de esta capa es la persistencia del estado de negocio, muy frecuentemente, usando una base de datos relacional.

Mi idea es tomar un ejemplo (posiblemente un dominio como uno del libro de Jimmy Nilsson), y desarrollarlo usando estas ideas, mostrando código concreto en Java y en .NET. En algún punto, discutiré sobre generación de código desde un modelo abstracto, pero no será el foco de esta serie de posts.

Fuentes consultadas:

Domain-Driven Design, Tackling Complexity in the Heart of Software, de Eric Evans.
Applying Domain-Driven Design and Patterns: With Examples in C# and .NET, de Jimmy Nilsson
.NET Domain-Driven Design with C#, Problem, Design, Solution, de Tim McCarthy. (Hay una sección en el blog de Tim dedicado a este libro).

Pueden bajar libremente

Domain-Driven Design Quickly

desde InfoQ.

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com

El camino hacia el Modelo de Dominio y Domain-Driven Design

lopez — Wed, 03 Sep 2008 10:34:48 GMT

Por años, la comunidad de desarrolo de software ha luchado contra la complejidad y el cambio. El desarrollo de software es uno de las actividades humanas con más niveles de detalle: debemos captar la imagen completa del sistema, y a la vez, tomar en cuenta cada pequeño detalle. Un desarrollador o un equipo de desarrolladores tienen que manejajar un montón de concptos, estilos de arquitectura, patrones de diseño e implementación, lenguajes, tecnologías, mejores prácticas y aún más: tiene que ejercitar los "soft skills" de comunicación con otros interesados en el proyecto.

Todo esto puede ser una tarea intimidante.

Muchos paradigmas emergieron en las últimas décadas, notablemente el orientado a objeto. Pero toma caminos divergentes: uno fue el purismo académico, con Smalltalkers y otros, que hicieron una gran tarea difundiendo objetos, pero que siguieron trabajando en aplicaciones, digamos, de nicho, no cruzando el abismo para llegar a la corriente principal de desarrollo (supongo que la fragmentación de Smalltalk en diverss dialectos fue una de las razones para el estado actual de la comunidad ST). No me malentiendan: Smalltalk tiene un comunidad fuerte y viva, pero no es uno de las tecnologías con muchas aplicaciones empresariales para mostrar.

C++ fue el primer lenguaje popular que dió "objetos para las masas", pero con la aparición de tecnologías complicadas (¿recuerdan la API desnuda de Windows? ¿O cualquier API de GUI?) y la explosión del mercado de PC, la corriente principal de desarrollo fue tomada por lenguajes derivados de xBase, y Delphi y Visual Basic, este último no tiene soporte de objetos hasta la versión 3, y nunca soporte de herencia. (Visual Basic fue un "matador" de ideas hermosas, como el lenguaje Actor: una extensión orientada a objetos del lenguaje Forth, con soporte nativo de GUI, implementado en Windows). (Sí, también tomemos nota de COBOL: este lenguaje fue y aún es el lenguaje principal en muchos ambientes).

Java hizo su aparición a mediados de los 90, dando aire fresco a la programación (yo nunca programé con VB 6.0: después de encontrar el paraíso Java, quién quería lidiar con Apartment Thread Models y todo el lío COM). Teníamos una librería de clases, verdaderos objetos, pero más: nosotros fuimos bendecidos por un "garbage collector", recolector de basura. Los nuevo "patrones de diseño" podían ser adoptados de forma masiva. Los objetos comienzan a estar en todas partes. Aparecen frameworks.

Pero algo estaba faltando: aunque los frameworks tomaron ventaja del uso de objetos, las implementaciones de negociones de muchas aplicaciones no reflejaban las nuevas capacidades. El elusivo Modelo de Dominio era un "santo grial" que no era fácil de encontrar. El trabajo de Sun con J2EE fué un fracaso parcial para armar modelos de dominio en Java. Cuando .NET nace, Microsoft no repite el error, y en sus primeros ejemplos y escritos de Pattern and Practices, no usan ninguna de los ideas de Modelo de Dominio (supongo que todavía son reluctantes a adoptar un Modelo de Dominio, LINQ to SQL es aún una bestia orientada a datos, la esperanza que tenemos es el Entity Framework).

La comunidad de Java tiene un gran conjunto de herramientas y librerías de código abierto, desde Ant a Maven a Tomcat y más. La simplicidad de la programación POJO (Plain Old Java Objects), junto con soluciones no intrusivas de persistencia (notablemente Hibernate), tomó un nuevo camino para alcanzar una más clara implementación de un modelo de dominio.

.NET entró tarde en el juego: mucha de las herramientas y ejemplos en el mundo .NET eran centradas u orientadas a datos, con datasets, y características de enlace a datos en todas las presentaciones (WinForms y ASP.NET). La comunidad .NET aprendió de la experiencia de la comunidad de Java, y en los últimos años, tenemos las ideas de Modelo de Dominio implementado en ambos mundos.

Eric Evans escribió un libro seminal sobre sus ideas de Domain-Driven Development, donde el Modelo de Dominio no es un artefacto más, sino el corazón del software a desarrollar. El va más allá de Modelo de Dominio, describiendo nuevos patrones y maneras de implementarlo. El libro explica el proceso para crear y descubrir un modelo, usando un lenguaje ubicuo (compartido con los usuarios), y cómo mejorar el modelo a lo largo del proceso de desarrollo.

Implementaciones de modelo de dominio, y DDD, son grandes tópicos a tratar. Quiero comenzar a escribir sobre esos temas, discutiendo varios puntos, y dando ejemplos concretos en Java y .NET. No es una tarea fácil, así que no esperen un post diario: el trabajo tomará tiempo.

Por ahora, pueden visitar mi colección de enlaces sobre DDD en:

http://del.icio.us/ajlopez/ddd

Algunos de mis anteriores posts sobre DDD:

Mini Book Domain Driven Design Quickly

Domain-Driven Design Resources

Enlaces y Recursos Domain-Driven Design

Domain-Driven Design

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com

Generando código para NHibernate (Parte 3)

lopez — Mon, 29 Oct 2007 09:17:00 GMT

Siguiendo con la serie

Generando código para NHibernate (Parte 1)
Generando código para NHibernate (Parte 2)

del ejemplo de Omar del valle Rodriguez, tengo una nueva versión del ejemplo, que genera aplicaciones con AjGenesis. Gracias desde acá, a las sugerencias de Omar, y de Fabio Maulo. He incorporado algunas características, como:

- Uso de NHibernate 1.2

- Manejo de mapeo de subclases en .hbm por separado

- Propiedades virtuales en las entidades

- Dos nuevas aplicaciones generadas

Pueden bajar el ejemplo AjOmar Versión 1.1 (es el archivo AjOmar-v1.1.zip) desde la página de ejemplos de AjGenesis.

El modelo

Como siempre, la idea de AjGenesis es basarse en un modelo libre, donde uno especifica lo que le interesa modelar. En el caso de este ejemplo, se modelan entidades, y a partir de esa información se generan aplicaciones completas. El modelo prácticamente no cambió desde la anterior versión (ver Parte 2), en el archivo Projects/AjOmar/Project.xml:

<Project>
    <Name>AjOmar</Name>
    <Description>Example AjOmar for (N)Hibernate</Description>
    <Prefix>AjOm</Prefix>
    <Domain>com.ajomar</Domain>
    <CompanyName>ajomar</CompanyName>
    <Model>
        <Entities>
            <Entity Source="Entities/Client.xml"/>
            <Entity Source="Entities/Company.xml"/>
            <Entity Source="Entities/User.xml"/>
        </Entities>
    </Model>
</Project>

Como había pedido Omar, Company y User heredan de Client. En la base de datos se usan tres tablas, y el NHibernate hace la magia del mapeo en este dominio con entidades relacionadas por herencia.

Como antes, también se especifican los elementos de tecnología, como la base de datos a usar, el usuario y contraseña a usar en los strings de conección, y otros detalles. Esto permite cambiar la tecnología, sin cambiar el modelo de arriba. Un ejemplo en el archivo Projects/AjOmar/Technologies/VbNet2Nh.xml:

<Technology>
    <Programming>
        <Dialect>VbNet2Nh</Dialect>
    </Programming>
    <Database>
        <Dialect>MsSql</Dialect>
        <Name>AjOmar</Name>
        <Username>sa</Username>
        <Prefix>ajom_</Prefix>
        <Host>(local)</Host>
    </Database>
    <NHibernate>
        <Dialect>NHibernate.Dialect.MsSql2000Dialect</Dialect>
    </NHibernate>
</Technology>

Deberá adaptar este archivo si necesita ajustar esos datos.

Siguiendo algunas recomendaciones de Fabio Maulo, ahora hay un .hbm por entidad. Ejemplo generado en Build/AjOmar/VbNet2Nh/Src/AjOmar.Data/Company.hbm.xml:

<?xml version="1.0" encoding="utf-8" ?> 
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
    assembly="AjOmar.Entities"
    namespace="AjOmar.Entities"
    >
    <joined-subclass name="Company" table="ajom_companies" extends="Client">
        <key column="Id" />
        <property name="CompanyName" type="String"/>
        <property name="ContactName" type="String"/>
    </joined-subclass>
</hibernate-mapping>

Las aplicaciones

Se pueden generar aplicaciones completas, con proyectos y solución web. La generación se invoca con comando de línea, como se explica en la Parte 2. Hay que agregar el directorio bin del AjGenesis en el path de ejecución para que funcionen.

Ahora están habilitados cuatro generaciones de soluciones:

GenerateProject AjOmar VbNet2Nh
GenerateProject AjOmar CSharp2Nh
GenerateProject AjOmar VbNet2DDDNh
GenerateProject AjOmar CSharp2DDDNh

Los dos primeros generan aplicaciones VB.NET y C Sharp, con ASP.NET 2.x, y acceso a datos usando DAOs que usan NHibernate.

Los dos nuevos comandos generan aplicaciones con VB.NET y C Sharp, que utilizan algunas ideas de Domain-Driven Design.

Generando DDD

Las nuevas soluciones generadas, tienen varios proyectos de librerías de clases:

AjNHibernate: contiene las clases para el manejo de las llamadas al NHibernate, como configuración, factoría y obtención de sesiones.
AjOmar.Domain: contiene las Entities, Services, y Repositories, a la Evans. No hay conceptos de Value Objects, o Aggregates. Los servicios se llaman Manager, para distinguirlos de la fachada de servicio que uso en Application.
AjOmar.Application: la capa que coordina las llamadas al Dominio, desde la presentación.

Y como antes, hay una aplicación web AjOmar.WebClient.

Próximos pasos

Tengo que generar aplicaciones similares para Hibernate, Java, y MySql. La idea es que sirva como prueba de concepto: desde un mismo modelo, se pueden generar aplicaciones implementadas con distintas tecnologías.

Habrá que estudiar e implementar el manejo de nulos, restricciones por tamaño de campo, y mejorar la apariencia de las aplicaciones generadas.

Hay que mejorar (y probar) el manejo de relaciones uno a varios, o varios a uno. Lo tengo implementado en los ejemplos AjGenesisExamples3, pero debería pasar ese código de plantillas y adaptarlo para este ejemplo.

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/

Generando aplicaciones con AjGenesis

lopez — Mon, 25 Jun 2007 08:20:00 GMT

En estos días, estuve escribiendo unos ejemplos de AjGenesis

http://www.ajlopez.com/ajgenesis

mi proyecto de código abierto de generación de código, para producir, desde un modelo, aplicaciones tanto en ASP.NET 1.x/2.x, como en JSP, tanto usando SQL Server en el primer caso, como con MySql en Java, y tanto con ADO.NET, como con NHibernate, Hibernate, ya sea con arquitectura de capas, como en capas a la Domain-Driven Design de Evans.

Sigo escribiendo esos ejemplos, pero ya hay algo publicado en

AjGenesisExamples3.zip

Usaremos la versión del proyecto que está actualmente en desarrollo:

AjGenesis-0.4.3.zip

Quisiera en este artículo, comentar cómo funciona y se construye, uno de esos ejemplos. Permítanme primero repasar algo sobre el proyecto. Primero, "the big picture":

Está escrito en Visual Basic .NET 1.x, y es código abierto, pues viene con una licencia tipo BSD, que permite utilizarlo en cualquier proyecto que quieran. Se puede usar como librería, invocado desde nuestro proyecto, se puede invocar desde la línea de comando, o puede ser utilizado desde el poderoso NAnt (esto último me permitió organizar mejor las tareas que realiza el generador de código).

En la página del proyecto (y en el proyecto mismo) hay varios ejemplos, que generan código desde un modelo, usando plantillas. Los ejemplos generan código PHP, Java, JSP, VB.NET, C#, ASP.NET, y hasta scripts de base de datos y procedimientos almacenados. Quisiera destacar dos puntos:

- El modelo del que parte es totalmente definible por el usuario

- Las tareas y plantillas a aplicar son totalmente programables y controlables

Esto lo diferencia de otros generadores. Podemos construirnos nuestro propio modelo, y sus propias plantillas, para generar los artefactos de texto que prefiera. Otros sistemas parten de la base de datos, y sólo generan un grupo de artefactos de textos predefinidos (por ejemplo, POJOs, plain old java objects, o DAOs, Data Access Objects). Pero con AjGenesis puede generar el artefacto de texto que se nos ocurra.

Para comprender mejor que el modelo se puede construir y consumir como uno lo disponga, ver un artículo anterior:

Generando Código- Hello World con AjGenesis

Ahí se describen los pasos iniciales, y un modelo que es totalmente libre.

Creando una aplicación

Encaremos hoy algo más completo. Necesitamos armar una solución sencilla, con dos tablas, sobre una base de datos SQL Server, con código VB.NET 2.0, con interface web, capa de servicios, capa de datos, entidades y componentes de negocio a la Microsoft. Queremos generar la solución, los proyectos, los scripts de creación de la base, y procedimientos almacenados. Este ejemplo está incluido en los ejemplos AjGenesisExamples3.zip. Primer paso: escribir el modelo.

El proyecto

En un directorio de proyectos de los ejemplos que acompañan este artículo, hay un directorio Projects/AjFirstExample.

En ese directorio está el archivo Project.xml que contiene el modelo.

<Project>
<Name>AjFirstExample</Name>
<Description>First Example using AjGenesis</Description>
<Prefix>AjFE</Prefix>
<Domain>com.ajlopez</Domain>
<CompanyName>ajlopez</CompanyName>
<Model>
   <Entities>
      <Entity Source="Entities/Customer.xml"/>
      <Entity Source="Entities/Supplier.xml"/>
   </Entities>
</Model>
</Project>

Recordemos: el modelo es libre. Acá definimos, para los templates que vamos a usar, las entidades de nuestro modelo: customers y suppliers.

Las entidades

Para que un archivo XML no resulte terriblemente largo, AjGenesis permite que cualquier nodo del modelo se especifique en un archivo aparte. Es un criterio que he usado para definir cómo se escribe el modelo: el XML resultante no debe herir a la vista, debe ser entendible y abarcable en una lectura.

En el Project.xml, eso aparece en el caso de las entidades, con el atributo Source. Examinemos una entidad, escrita en Entities/Customer.xml:

<Entity>
<Name>Customer</Name>
<Description>Customer Entity</Description>
<SetName>Customers</SetName>
<Descriptor>Customer</Descriptor>
<SetDescriptor>Customers</SetDescriptor>
<SqlTable>customers</SqlTable>
<Properties>
<Property>
<Name>Id</Name>
<Type>Id</Type>
</Property>
<Property>
<Name>Name</Name>
<Type>Text</Type>
<SqlType>varchar(200)</SqlType>
</Property>
<Property>
<Name>Address</Name>
<Type>Text</Type>
<SqlType>text</SqlType>
</Property>
<Property>
<Name>Notes</Name>
<Type>Text</Type>
<SqlType>text</SqlType>
</Property>
</Properties>
</Entity>

Hay atributos de la entidad, como su nombre y descripción, en singular y plural, que sirve para nombrarlas en las páginas resultantes, o dentro del código. Las propiedades son los campos a mantener en cada entidad. Vemos que en este ejemplo, no hay más que datos dentro de una entidad.

Aparte de las entidades, en otro directorio, Technologies, se especifica el modelo dependiente de la tecnología, como VbNet2:

<Technology>
<Programming>
    <Dialect>VbNet2</Dialect>
  </Programming>
<Database>
    <Dialect>MsSql</Dialect>
    <Name>AjFirstExample</Name>
    <Username>sa</Username>
    <Prefix>ajfe_</Prefix>
    <Host>(local)</Host>
</Database>
</Technology>

Las plantillas

En el directorio Templates/VbNet2 encontramos

Son las plantillas para generación de código VB.Net 2.0. También encontraremos plantillas para C# 1.x y 2, Vb.NET 1, Java. Hay plantillas para usar Nhibernate, Hibernate, JSP, MySql, y conceptos de Domain-Driven Design. Todo desde el mismo modelo. Tomemos como muestra una plantilla, la que genera la entidad en Visual Basic, EntityVb.tpl:

<#
message "Generating Entity ${Entity.Name}"
include "Templates/VbNet2/VbFunctions.tpl"
include "Templates/VbNet2/Prologue.tpl"
#>
'
' Project ${Project.Name}
' ${Project.Description}
' Entity ${Entity.Name}
' ${Entity.Description}
'
'
Public Class ${Entity.Name}

' Private Fields

<# for each Property in Entity.Properties
message "Procesando Campo ${Property.Name}"
#>
Private m${Property.Name} as ${VbType(Property)}
<#
end for
#>
' Default Constructor

Public Sub New()
End Sub

' Public Properties

<#
for each Property in Entity.Properties
    message "Procesando Propiedad ${Property.Name}"
#>
Public Property ${Property.Name}() as ${VbType(Property)}
Get
    Return m${Property.Name}
End Get
Set(ByVal Value As ${VbType(Property)})
    m${Property.Name} = Value
End Set
End Property
<#
end for
#>

End Class

Como antes, se usan estructuras de control, y recorrido de una entidad del modelo. No se maneja el XML. El formato XML es la forma de serialización del modelo. Durante el proceso de la plantilla, el modelo ya está en memoria, accesible desde variables dinámicas.

Los pasos

Ahora tenemos más archivos a generar: desde las páginas ASPX, y su código asociado, los proyectos de fachada de servicio, entidades, acceso a datos, el archivo de solución, y más. Para automatizar esta generación, el ejemplo tiene varios archivos de tareas, en el directorio Tasks, donde se describen los pasos a ejecutar. Hay dos grandes tareas: los pasos a ejecutar independientemente de la tecnología elegida, como completar el modelo, revisarlo, y las dependientes de la tecnología, como generar tal archivo JSP o ASPX, dependiendo de si queremos Java o .NET.

La tarea de completar el modelo está a cargo de Tasks\BuildProject.ajg, que comienza con:

'
' Build Project
' Complete the Project Data
' Project must be loaded in global variable Project
'

PrintLine "Completing Project ${Project.Name}"

include "Templates/EntityFunctions.tpl"
include "Templates/Utilities.tpl"

if not Project.Title then
Project.Title = Project.Name
end if

if not Project.Version then
Project.Version = "1.0.*"
end if

if not Project.SystemName then
Project.SystemName = Project.Name
end if

Acá incluye algunas funciones auxiliares, y luego comienza a completar el modelo que reside en la variable Project. Ejemplo: si falta Project.Title le coloca como título el Project.Name. Prosigue:

for each Entity in Project.Model.Entities
PrintLine "Entity " + Entity.Name

for each Property in Entity.Properties
PrintLine "Property " & Property.Name

    if not Property.Description then
      Property.Description = Property.Name
    end if

    if not Property.Title then
      Property.Title = Property.Description
    end if

    if Property.Type="Id" and not Property.SqlType then
      Property.SqlType="int"
    end if

    if Property.SqlType and not Property.SqlColumn then
      Property.SqlColumn = Property.Name
    end if

    if Property.Type="Id" and not Entity.IdProperty then
      Entity.IdProperty = Property
    end if

if Property.Reference then

...

Mas adelante, se ejecutan las tareas de tecnología. Como ejemplo, veamos un fragmento de Tasks\BuildVbNet2.ajg:

<#
include "Templates/Utilities.tpl"
include "Templates/VbNet2/UtilitiesVb.tpl"

message "Creating Directories..."

FileManager.CreateDirectory(Project.BuildDir)
FileManager.CreateDirectory("${Project.BuildDir}/Sql")
FileManager.CreateDirectory("${Project.BuildDir}/Src/${Project.Name}.Entities")
FileManager.CreateDirectory("${Project.BuildDir}/Src/${Project.Name}.Entities/My Project")
FileManager.CreateDirectory("${Project.BuildDir}/Src/${Project.Name}.Data")
FileManager.CreateDirectory("${Project.BuildDir}/Src/${Project.Name}.Data/My Project")
FileManager.CreateDirectory("${Project.BuildDir}/Src/${Project.Name}.Services")
…

En este fragmento, se crean los directorios necesarios para albergar la solución. El nombre del directorio se extrae del modelo desde ${Project.BuildDir}.

Generando la solución

Podríamos lanzar las tareas desde la línea de comando, pero tenemos un build armado para el Nant, uno para cada tecnología. Ejecutamos las tareas build, buildsql, y deploysql de AjFirstExampleVbNet2.build:

En el directorio Build/AjFirstExample/VbNet2/Sql quedan los scripts de creación de la base y procedimientos almacenados. Y en el directorio hermano Src, sorpresa, tenemos la solución ya preparada:

Encontramos varios proyectos armados. Si levantamos la solución en el Visual Studio 2005, aparece todo el código generado:

Con otro archive build AjFirstExampleCSharp2.build, generamos la misma solución en CSharp:

Encontrarán otros proyectos y ejemplos de .build, que usan NHibernate, Hibernate, JSP, y conceptos de DDD.

Reflexiones

Claro, no todo se puede generar automáticamente. Es importante tener siempre presente esto. Pero en el día a día, reconozcamos que tenemos cantidad de texto repetitivo, tareas que bien podemos encargar al propio software.

Recordemos siempre: el modelo es libre. Los ejemplos presentados son solamente ejemplos: podemos general el modelo que queremos, y escribir las plantillas que necesitamos. Es importante escribir las plantillas de forma que el código generado sea similar al que hubiéramos generado nosotros. Si no nos sentimos cómodos con el código generado, si no tiene nuestro estilo, nuestra experiencia, terminamos generando algo que no entendemos.

Otra reflexión: el modelo debe ser independiente de la tecnología. En el ejemplo final, hemos visto cómo, desde el mismo modelo, se puede generar la solución para VB.NET2, y para CSharp. Encontrarán las plantillas para generarla con Nhibernate, con DDD, con Hibernate, con Java y JSP, y podemos escribir la que necesitamos.

El software debe ayudarnos a generar software. Nuestra experiencia cuenta: lo que aprendimos de hacer aplicaciones, podemos volcarlo en esta especie de sistema experto, generador de código. Justamente, en el futuro, espero poder incorporar al proyecto, en las plantillas, más toma de decisiones: así como volcamos nuestra experiencia en escritura de aplicaciones, podemos incorporar nuestro conocimiento acumulado sobre patrones, arquitectura, estilos de programación.

Y al ser de código abierto, AjGenesis permite que lo extendamos, a nuestro gusto y necesidad.

Se aceptan sugerencias, historias de uso. Pueden escribir comentarios a este artículo, o escribirme. Desde ya, muchas gracias por cualquier "feedback".

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/

Mini Book Domain Driven Design Quickly

lopez — Tue, 12 Dec 2006 19:48:17 GMT

InfoQ ha publicado un mini-libro (versión impresa con costo, hay un PDF para bajase libremente, más información al final de este artículo), que es un resumen sobre DDD, del libro de Eric Evans.

This book is a short, quickly-readable summary and introduction to the fundamentals of DDD; it does not introduce any new concepts; it attempts to concisely summarize the essence of what DDD is, drawing mostly Eric Evans' book, as well other sources since published such as Jimmy Nilsson's Applying Domain Driven Design, and various DDD discussion forums. Chapters of the book include:

Building Domain Knowledge
The Ubiquitous Language
Model Driven Design
Refactoring Toward Deeper Insight
Preserving Model Integrity
Interview with Eric Evans on why DDD matters today

About the book

Domain-Driven Design Quickly was produced by InfoQ.com, summarized primarily by Abel Avram and with Floyd Marinescu as managing editor. Special thanks to Eric Evans for his support and Vladimir Gitlevich and Dan Bergh Johnsson for their detailed reviews. The intention of this book is to get an introduction to Domain-Driven Design into as many hands as possible, to help it become mainstream.

Más información:

http://www.infoq.com/minibooks/domain-driven-design-quickly

Yo descargué el .pdf desde

Download this book FREE (PDF)

Tal vez les pida registrarse.

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/

Enlaces y Recursos Domain-Driven Design

lopez — Sat, 09 Dec 2006 09:18:00 GMT

Hola gente!

Tengo en mi colección de enlaces, en mis apuntes para mis charlas, algunos enlaces sobre Domain-Driven Design, que quisiera compartir, no estarán muy ordenados, pero me sirven de mucho:

El sitio de Eric Evans
http://domaindrivendesign.org

Mi colección de enlaces en Delicious sobre DDD
http://del.icio.us/ajlopez/ddd

Organizing Domain Logic
http://weblogs.asp.net/pgielens/archive/2006/08/08/Organizing-Domain-Logic.aspx

Spring XT
http://springxt.sourceforge.net/index.php/Main_Page

Anemic Domain Model
http://www.martinfowler.com/bliki/AnemicDomainModel.html

Notifications
http://www.martinfowler.com/eaaDev/Notification.html

Fluent Interface
http://www.martinfowler.com/bliki/FluentInterface.html

Specifications
http://www.martinfowler.com/apsupp/spec.pdf
http://www.martinfowler.com/bliki/SpecificationByExample.html
http://sbtourist.blogspot.com/2006/01/case-for-specifications.html
http://sbtourist.blogspot.com/2006/02/another-case-for-specifications.html
http://sbtourist.blogspot.com/2006/05/idea-for-composite-specifications.html
http://sbtourist.blogspot.com/2006/05/implementing-composite-specifications.html
http://www.jeffperrin.com/index.php/2006/06/28/specification-pattern-with-predicates/

Ver todo lo de Sergio Bossa
http://sbtourist.blogspot.com
http://del.icio.us/sbtourist/Domain-Driven-Design

Spring Modules XT
https://springmodules.dev.java.net/docs/reference/0.5/html_single/#about

Hay un ejemplo carserv.zip con DDD en Java
http://www.bettersoftwarefaster.com/
http://www.myjavaserver.com/~bswf/downloads/carserv.zip

Applying the Application Layer in Domain-Driven Design
http://weblogs.asp.net/pgielens/archive/2006/05/31/Applying-the-Application-Layer-in-Domain-Driven-Design.aspx

DDD: Can I drop my Service Layer?
http://peter.jteam.nl/?p=17

Concurrency control in databases: Introduction
http://peter.jteam.nl/?p=8

y todo lo que escribe Peter Veenjter sobre DDD
http://peter.jteam.nl/?cat=6

Constructing View objects with the Builder pattern
http://sbtourist.blogspot.com/2006/07/constructing-view-objects-with-builder.html

Domain-Driven Design: Model Driven Architecture Done Right?
http://hinchcliffe.org/archive/2005/03/20/189.aspx

A Better Path to Enterprise Architectures
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/sessfin00.asp

Puede ser interesante este articulo de Hibernate con un Modelo de Dominio sencillo
http://www.theserverside.net/tt/articles/showarticle.tss?id=NHibernate

Avoiding Anemic Domain Models with Hibernate
http://wrschneider.blogspot.com/2005/01/avoiding-anemic-domain-models-with.html

What is a View in Domain Driven Design?
http://billhamaker.wordpress.com/2006/08/03/what-is-a-view-in-domain-driven-design/

A Proposal for an Abstract Domain Pattern « Bill Hamaker’s Blog
http://billhamaker.wordpress.com/2006/08/24/a-proposal-for-an-abstract-domain-pattern/

Un ejemplo de Repositorio
http://abc.truemesh.com/archives/000464.html

Ver el blog que refleja el grupo ddd
http://blog.gmane.org/gmane.comp.programming.domain-driven-design

Steve Eichert - Domain Driven Design
http://www.emxsoftware.com/Domain+Driven+Design

Hooking your Domain Model and UI Layer
http://www.emxsoftware.com/Domain+Driven+Design/Hooking+your+Domain+Model+and+UI+Layer

Keeping the Domain Model free from Persistence Logic
http://weblogs.asp.net/pgielens/archive/2005/07/29/420995.aspx

DDD: Aggregates & Repositories
http://www.emxsoftware.com/Domain+Driven+Design/DDD+Aggregates++Repositories

How Domain Driven Design changed my way of thinking
http://www.emxsoftware.com/Domain+Driven+Design/How+Domain+Driven+Design+changed+my+way+of+thinking

A quick comparison of Domain Model vs. Manager (Service) Model
http://www.emxsoftware.com/SOA/A+quick+comparison+of+Domain+Model+vs+Manager+Service+Model

Implementing Manager Models with a domain model
http://www.emxsoftware.com/SOA/Implementing+Manager+Models+with+a+domain+model

Vote Manager Model, Domain Model, or Both
http://www.emxsoftware.com/SOA/Vote+Manager+Model+Domain+Model+or+Both

Does SOA require Object-Message mappers It depends
http://weblogs.asp.net/fbouma/archive/2004/03/06/85105.aspx

Domain-Specific Modeling and Model Driven Architecture
http://www.bptrends.com/publicationfiles/01-04%20COL%20Dom%20Spec%20Modeling%20Frankel-Cook.pdf#search=%22domain%20driven%20example%22

Domain driven design implemented in Spring 01
http://forum.springframework.org/showthread.php?t=19429
Domain driven design implemented in Spring 02
http://forum.springframework.org/showthread.php?t=19429&page=2
Domain driven design implemented in Spring 03
http://forum.springframework.org/showthread.php?t=19429&page=3
Domain driven design implemented in Spring 04
http://forum.springframework.org/showthread.php?t=19429&page=4
Domain driven design implemented in Spring 05
http://forum.springframework.org/showthread.php?t=19429&page=5
Domain driven design implemented in Spring 06
http://forum.springframework.org/showthread.php?t=19429&page=6
Domain driven design implemented in Spring 07
http://forum.springframework.org/showthread.php?t=19429&page=7
Domain driven design implemented in Spring 08
http://forum.springframework.org/showthread.php?t=19429&page=8

http://forum.springframework.org/showthread.php?t=19429&page=5

Domain Driven Design vs Data Driven Design -- Domain Driven Design
http://vikasnetdev.blogspot.com/2006/07/domain-driven-design-vs-data-driven.html

Domain-Driven Framework Layering in Large Systems
http://www.riehle.org/computer-science/research/2000/cs-2000-gebos.pdf#search=%22domain%20driven%20example%22

Test Driven Development with Domain Driven Design – Part 1
http://donxml.com/allthingstechie/archive/2005/12/15/2348.aspx

Test Driven Development with Domain Driven Design – Part 2
http://donxml.com/allthingstechie/archive/2005/12/18/2361.aspx

Domain-Driven Design, the quest for software perfection
http://coding.mu/index.php/archives/2005/02/11/domain-driven-design-the-ultimate-solution/

Some thoughts about DDD: Introduction
http://peter.jteam.nl/?p=16

DDD: Can I drop my Service Layer? (en Arquitectura)
http://peter.jteam.nl/?p=17

Domain-Driven Design Using Active Record in .NET
http://davidhayden.com/blog/dave/archive/2006/06/21/2995.aspx

Explore model-driven development (MDD) and related approaches: A closer look at model-driven development and other industry initiatives
http://www-128.ibm.com/developerworks/library/ar-mdd3/

RAD That Ain't Bad: Domain-Driven Development with Trails
http://today.java.net/pub/a/today/2005/06/23/trails.html

Trails and Firebird
http://www.cstengel.de/tutorial/trails_firebird_tutorial/

Trails
https://trails.dev.java.net/

The Development Abstraction Layer
http://www.joelonsoftware.com/printerFriendly/articles/DevelopmentAbstraction.html

Advnace Mocking Scenarios With Active Record (using Rhino Mocks)
http://www.ayende.com/Blog/2006/04/14/AdvnaceMockingScenariosWithActiveRecordUsingRhinoMocks.aspx

Testing ActiveRecord objects
http://www.ayende.com/Blog/2006/04/14/TestingActiveRecordObjects.aspx

ADO.NET Team Blog
http://blogs.msdn.com/adonet/

LINQ to Entities vs. LINQ to SQL - What should I use and when?
http://dotnetaddict.dotnetdevelopersjournal.com/adoef_vs_linqsql.htm

Trouble with Testing "ActiveRecord" objects
http://steve.emxsoftware.com/NET/Trouble+with+Testing+ActiveRecord+objects

Repository vs ActiveRecord
http://geekswithblogs.net/gyoung/archive/2006/04/28/76647.aspx

Repository, the Foundation of Domain Driven Design
http://geekswithblogs.net/gyoung/archive/2006/05/03/77171.aspx

Lecture 23: Domain-Driven Design, Part 1
http://www.cs.colorado.edu/~kena/classes/6448/s05/lectures/lecture23.pdf
Lecture 23: Domain-Driven Design, Part 2
http://www.cs.colorado.edu/~kena/classes/6448/s05/lectures/lecture24.pdf
Lecture 23: Domain-Driven Design, Part 3
http://www.cs.colorado.edu/~kena/classes/6448/s05/lectures/lecture25.pdf
Lecture 23: Domain-Driven Design, Part 4
http://www.cs.colorado.edu/~kena/classes/6448/s05/lectures/lecture26.pdf
Lecture 30: Domain-Driven Design, Part 5 Supple Design
http://www.cs.colorado.edu/~kena/classes/6448/s05/lectures/lecture30.pdf#search=%22domain%20driven%20example%22

Domain-Driven Modeling with Aspects and Ontologies
http://www.st.informatik.tu-darmstadt.de:8080/ecoop2005/maw/acceptedPapers/Hruby.pdf#search=%22domain%20driven%20example%22

An End to End Domain Driven Development Framework
http://www.isis.vanderbilt.edu/publications/archive/Agrawal_A_10_0_2003_An_End_to_.pdf#search=%22domain%20driven%20example%22

Model View Presenter with ASP.NET
http://www.codeproject.com/useritems/ModelViewPresenter.asp#Downloads

Book Review: Applying Domain-Driven Design and Patterns
http://www.aspnetresources.com/blog/applying_ddd_patterns_book_review.aspx

The Vietnam of Computer Science
http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

Business domain-driven Java class hierarchies for Domino
http://www-128.ibm.com/developerworks/lotus/library/ls-Java_hierarchies/index.html

Applying Domain-Driven Design and Patterns With Examples in C# and .NET
http://codebetter.com/blogs/david.hayden/archive/2006/06/04/146045.aspx

http://www.theserverside.net/tt/books/addisonwesley/DomainDrivenDesign/DomainDrivenDesign.pdf

Next-Generation Data Access: Making the Conceptual Level Real
http://msdn.microsoft.com/vstudio/default.aspx?pull=/library/en-us/dnvs05/html/nxtgenda.asp

ADO.NET Tech Preview: Entity Data Model
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/ADONET_EDM.asp

http://mondragon.angeltowns.net/paradiso/AplicacionesProyectos.html

Ver los resources de
http://www.orm.net
http://sourceforge.net/projects/orm

Conceptual Queries using ConQuer-II
http://www.orm.net/pdf/ER97-final.pdf

ConQuer: a Conceptual Query Language
http://www.orm.net/pdf/ER96.pdf

Conceptual Queries
http://www.orm.net/pdf/ConceptQueries.pdf

Business Rules and Object Role Modeling
http://www.orm.net/pdf/dppd.pdf

Agent Oriented Enterprise Modeling Based on Business Rules
http://www.informatik.tu-cottbus.de/~gwagner/papers/EM-BR.pdf

Dual Schema Problem
http://devhawk.net/2006/03/28/The+Dual+Schema+Problem.aspx

Understanding and Using ValueModels
http://c2.com/ppr/vmodels.html

Más patrones
http://wiki.moredesignpatterns.com

El bueno de Ezequiel Jadib ha compilado

http://ejadib.wordpress.com/2006/11/20/nhibernate-and-domain-driven-design/

sobre una serie de artículos de Ben Scheirman:

A Journey with NHibernate - Part 1
A Journey With NHibernate - Part 2
A Journey With NHibernate (and DDD) - Part 3
A Journey with Domain Driven Design (and NHibernate) - Part 4
A Journey with Domain Driven Design (and NHibernate) - Part 5
A Journey with Domain Driven Design (and NHibernate) - Part 6
A Journey with Domain Driven Design (and NHibernate) - Part 7

Espero que les sirva

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/

Domain-Driven Design en Buenos Aires, Arquitectura .NET en Bahía Blanca

lopez — Sun, 03 Dec 2006 21:40:00 GMT

Esta semana tengo que dar, aparte de los cursos, dos charlas. Una en Buenos Aires, sobre Domain-Driven Design, en el Club de Programadores. El temario es algo ambicioso, pero creo que interesante: exploraremos las ideas de Eric Evans, y de cómo sugiere emplear el Modelo de Dominio como conductor en el diseño. Y comentaramos cómo implementarlo en la práctica. Seguramente, aprovecharé algún template de AjGenesis para producir artefactos como Repositories, Entities, Application Layer, y demás. Más información en

http://www.clubdeprogramadores.com/cursos/CursoMuestra.php?Id=307

Eso es el martes. El miércoles viajo a Bahía Blanca, para dar una charla sobre Arquitectura .NET paso a paso, organizada por el Grupo de Usuarios Microsoft. Me parece interesante plantear el tema viendo cómo aparecen conceptos de arquitectura, desde una simple aplicación web. Me reencontraré con Paola Piovano, Guillermo Reggiani, Marcos Melli, y cía. Más información en

http://www.mug.org.ar/Eventos/2496.aspx

Mientras, sigo desarrollando, dando cursos, y de vez en cuando, durmiendo... :-)

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/

Angel "Java" Lopez : Domain-Driven Design

Arquitectura de capas en Domain-Driven Design

El camino hacia el Modelo de Dominio y Domain-Driven Design

Generando código para NHibernate (Parte 3)

El modelo

Las aplicaciones

Generando DDD

Próximos pasos

Generando aplicaciones con AjGenesis

Creando una aplicación

El proyecto

Las entidades

Las plantillas

Los pasos

Generando la solución

Reflexiones

Mini Book Domain Driven Design Quickly

Table of contents

About the book

Enlaces y Recursos Domain-Driven Design

Domain-Driven Design en Buenos Aires, Arquitectura .NET en Bahía Blanca