Les modèles de domaine “anémiques”

De par notre expérience en tant qu’auditeurs techniques, nous avons observé de plus en plus de situations de ‘Modèles de domaine anémiques’. Poussés par un manque de compréhension du principe de ‘Séparation des problèmes’, il semble que certains développeurs non expérimentés aient un peu trop tendance à créer des multitudes de classes en déclinant ce qu’ils ont compris des principes d’architecture dans du code structuré de manière très maladroite et inefficace.

Revenons à la base telle que décrite il y a quelques années par Martin Fowler :

Le symptôme de base d’un modèle de domaine anémique, c’est que, à première vue, il ressemble à un modèle normal. Il y a des objets dont la plupart sont nommés avec des noms de domaine et ces objets sont reliés avec une relation de structure riche comme les vrais modèles de domaines. Le hic c’est qu’il n’y a pas plus de comportement entre ces objets qu’entre des réceptacles de lecture et mise à jour de propriétés. Bien souvent ces modèles sont livrés avec des règles de conception qui empêchent de mettre une quelconque logique de domaine dans les objets. Au lieu de cela il existe un ensemble de d’objets service qui capturent toute la logique de domaine. Ces services évoluent au-dessus du modèle de domaine et l’utilisent uniquement pour les données.

C’est exactement ce que nous essayons d’éviter dans nos projets : ces classes de logique métier vides, souvent encapsulées dans une couche supplémentaire de services procéduraux qui au final crée juste une conception de style procédural. En outre, comme nombreux sont ceux qui pensent que les objets anémiques sont de vrais objets, ils oublient complètement la raison d’être de la conception orientée-objet.

A l’inverse, Eric Evans affirme au sujet de la couche domaine (ou couche modèle) :

Chargée de représenter les concepts métier, l’information sur la situation et les règles du métier. Etat qui reflète comment la situation métier est contrôlée et utilisée, même si les détails techniques de stockage sont délégués à l’infrastructure. Cette couche est le cœur du logiciel métier.

Et nous sommes totalement alignés sur cette vision : en particulier aujourd’hui, à l’abord d’une nouvelle vague technologique (e.g. HTML5 & WinRT) ; la véritable clé, c’est votre architecture. Si vous avez déjà cette couche de domaine riche, les couches supérieures devraient simplement s’appuyer sur elle ; les coquilles vides fournissent des interactions avec l’utilisateur au cœur de votre logiciel métier. Par conséquent, intégrer une nouvelle plateforme (allant du client riche au web ou des formulaires Web au MVC par exemple) se résume à la création de cette coquille.

C’est exactement la raison pour laquelle nous avons créé CodeFluent Entities, avec pour 1^er objectif de générer un vrai modèle métier objet .NET : le produit génère une couche domaine .NET complète comprenant vos logiques métier et qui peut être utilisée de manière transversale pour toutes les technologies .NET (Windows Forms, WPF, SharePoint, ASP.NET MVC, ASP.NET Web Forms, Windows workflows etc…) ; et de cette façon sécuriser votre investissement.

En tant que producteur modèle métier objet (générateur de code) il peut générer :

• Les classes : des classes de base à l’ancienne (ne provenant pas d’une classe de base technique), lisibles par l’homme, toutes partielles et extensibles facilement par un développeur avec mise en œuvre extensive d’interfaces (ICloneable, IComparable, IDataErrorInfo, IEquatable, INotifyPropertyChanged, etc) pour faciliter le développement des couches supérieures et déboguable facilement dans la mesure où aucun code n’est généré dynamiquement à l’exécution,
• Les énumérations : dans la mesure où CodeFluent Entities n’est pas un ORM, vous pouvez créer vos propres énumérations .NET ou réutiliser des énumérations existantes,
• Les espaces de nommage multiples : comme il est courant d’avoir plus d’un domaine dans de vraies applications métier,
• Les règles : pour valider vos données, mettre en place des opérations et implémenter votre logique métier,
• Les méthodes : créer vos propres méthodes à côté de celles générées par défaut,
• Les objets légers comme les structures ou les objets non-persistants utiles pour recueillir des informations d’entités transversales,
• Des composants tels qu’un gestionnaire d’objets binaires de grande taille http pour manipuler les blobs dans des environnements web ou un gestionnaire de cache basé sur le gestionnaire de cache ASP.NET standard et plus encore.

Enfin, nous ne pensons pas que les outils puissent générer des applications entières, ce n’est pas ce que nous disons, car développer des applications est une des opérations les plus complexes qui nécessite plus qu’un accès aux données et/ou des contrôles d’IHM. Ce que nous prétendons, c’est que nous procurons un outil aux développeurs afin de les aider à construire les fondations solides de leurs applications .NET, basées sur un modèle de domaine cohérent, afin que les développeurs n’aient plus qu’à l’étendre et le compléter.

La recette que nous proposons avec CodeFluent Entities a pour finalité de créer des applications .NET basées sur une couche de domaine riche bâtie par l’outil et les développeurs, contenant toute la logique métier de votre application. Il s’agit d’une API complète et cohérente qui peut être utilisée sur les plateformes (x86, x64, bureau, web) à travers toutes les technologies (.NET 2 à 4) de sorte de sécuriser vos investissements.

Et même si vous n’envisagez pas d’utiliser notre outil, nous continuons de penser que c’ est une très mauvaise idée de suivre cette voie des ‘Modèles de domaine anémiques’ et que vous devriez créer des modèles de domaine réels, soit à la main, soit avec un autre outil qui le ferait correctement.

Daniel COHEN-ZARDI avec l’appui de l’équipe R&D de SoftFluent