Votre avis sur l'archi du projet codecampserver

[Sebastien Crocquesel]

Bonjour,

 

Attention pavé...

 

Le projet est le suivant : http://www.codeplex.com/codecampserver

 

Je souhaiterais que l'on discute sur les choix de conception que l'on retrouve dans de ce projet notamment dans le cadre d'une mise à jour de données :

De ce que j'en comprends, les grandes lignes sont les suivantes :

- Une couche domaine avec des objets anémiques et les interfaces repository (j'omet volontairement la couche de persistence)

- Une couche service avec des objets CommandMessage et CommandHandler (un par type de message). Le handler dépend des repository et autres services pour manipuler les objets du domaine.

- Une couche UI qui génère les Inputs. La techno web est asp mvc et les binders sont utilisés pour mapper sur les objet Input en ne faisant que de la validation de type.

- Une couche "BusinessRule" qui permet de faire le mapping entre un objet "Input" de la couche UI et les CommandMessage. C'est durant ce mapping qu'interviennent les règles de validations métiers.

 

- Pour les lectures, l'UI accède directement au repository et utilise un mapper pour mapper les objets du domaine sur des modèles de vue.

 

J'aime bien l'idée générale mais je coince au niveau du positionnement des règles métiers de validation qui comme on le voit sont tout en haut dans les couches.

D'autant que dans le découpage en projet, les objets du domaine sont dans un projet "Core" et la définition des règles de validation et de mapping UI->Command sont dans un projet "Infrastructure".

Le fait est que, je préfèrerait avoir ces règles dans la couche domaine mais qu'étant donnée qu'elles interviennent dans le mapping entre UI et Command, les déportées en l'état pose problème.

Je pense que pour supprimer cette référence, il faut des interfaces d'Input défini dans le domaine et implémentée dans l'UI.

 

Du coup, l'objet message est peut-être redondant. Autant, partir de l'input (qui devient le message quitte à faire un traitement supplémentaire dans le controller pour qu'il en soit ainsi) et mapper directement sur l'objet métier via le moteur de règle.

On replace le message au niveau domaine et comme point d'entrée à celui-ci. Un contrat par message/commande possible.

 

L'idée du message m'interesse beaucoup car, in fine, c'est facilement transportable, serializable et sécurisable via msmq.

Reste les lectures qui passerait sûrement par des messages de demande de données via un canal plus rapide que msmq.

 

Quelle serait la meilleur implémentation de ce concept. Est-ce du CQS ?

 

Si vous connaissez des projets de "références" sur ce type d'architecture, je suis preneur.

 

Merci d'avoir lu jusqu'au bout... ou pas :)

 

Sébastien