Grande évolutivité dans la conception basée sur domaine

Question

J'utilise DDD pour une application orientée service destinée à transmettre un volume élevé de messages entre un volume élevé de clients Web (c'est-à-dire des navigateurs). Parce que dans le contexte des fonctionnalités requises, le besoin de transmission l'emporte sur le besoin de stockage, j'aime l'idée de s'appuyer principalement sur la RAM et de minimiser l'utilisation de la base de données.

Cependant, je ne suis pas clair sur la façon d'architecturer cela du point de vue de l'évolutivité. Une batterie de serveurs Web crée une haute disponibilité des points de terminaison de service et un traitement de logique de domaine. Mais peu importe le nombre de serveurs que j'ai, il semble qu'ils doivent tous partager un référentiel commun afin que leurs données soient cohérentes.

Comment construire ce référentiel pour qu'il soit aussi évolutif que possible? Comment peut-il éclabousser un ensemble de machines physiques d'une manière telle que toutes les machines soient cohérentes et que chacun s'en moque si un autre tombe en panne? Etant donné que la base de données sera parfois utilisée pour toucher la base de données (par exemple, lorsqu'un client disparaît et que les messages qui lui sont destinés doivent être stockés jusqu'à son retour), comment organiser mon code et ma couche d'accès aux données? Sont-ils tous deux considérés comme "le référentiel"?

Answer 1

Il existe plusieurs façons de résoudre ce problème. Aucune réponse ne peut vraiment tout couvrir ...

Une méthode pour assurer votre évolutivité est simplement échelle du matériel. Ecrivez vos services Web pour qu'ils soient sans état afin que vous puissiez exécuter une batterie de serveurs Web (tous exécutant les mêmes services identiques, pointant vers la même base de données) et transformer votre base de données en cluster. Les bases de données en cluster s'exécutent sur plusieurs serveurs et fonctionnent sur le même stockage. Cependant, ce scénario peut devenir compliqué et coûteux assez rapidement.

Quelques liens intéressants:

• http://scale-out-blog.blogspot.com/2009/09/future-of-database-clustering.html
• http://en.wikipedia.org/wiki/Server_farm

Une autre méthode consiste à oeil à l'architecture. CQRS est un modèle architectural commun qui garantit l'évolutivité. Par exemple, ce modèle d'architecture - son nom signifie Command/Query Responsibility Segregation - crée différentes bases de données pour la lecture et l'écriture. Cela semble contradictoire, mais si vous l'étudiez, cela devient naturel et vous vous demandez pourquoi vous n'y avez jamais pensé auparavant. Autrement dit, la plupart des applications font beaucoup plus de lecture que d'écriture, et l'écriture tend à être beaucoup plus compliquée que la lecture (exigeant la validation des règles métier, etc.), alors pourquoi ne pas séparer les deux? Vous pouvez utiliser votre base de données transactionnelle coûteuse pour l'écriture, puis votre base de données bon marché, peut-être non SQL ou open source, sur plusieurs serveurs de lecture. Votre modèle de lecture est ensuite optimisé pour les écrans de vos applications, tandis que le modèle d'écriture est optimisé uniquement pour l'écriture et constitue en fait un ensemble de référentiels basé sur DDD.

Il n'y a tout simplement pas assez de place ici pour couvrir cette option en détail, mais CQRS est un bon moyen d'atteindre l'évolutivité et même la facilité de développement, une fois que vous avez un cadre CQRS en place. CQRS offre de nombreux autres avantages, tels que la facilité de l'audit (si vous le combinez avec la technique de «l'approvisionnement d'événements», qui est courante dans les environnements basés sur CQRS).

Quelques liens intéressants:

• http://cqrsinfo.com
• http://abdullin.com/cqrs
• http://blog.fossmo.net/post/Command-and-Query-Responsibility-Segregation-(CQRS).aspx

Answer 2

Êtes-vous prêt pour la lecture? Il y a beaucoup d'options, mais je crois que vous devriez commencer par en apprendre davantage sur les avantages des dbs NoSQL distribués modernes, et profiter de l'apprentissage de l'expérience acquise sur Facebook, LinkedIn et d'autres amis. Commencez ici:

• http://highscalability.com/
• http://nosql-database.org/