Voir le modèle et/ou le modèle de domaine?

Question

Bonjour à tous, J'essaie de trouver ce qui me convient le mieux dans un travail que je fais pour la plus grande partie.
La partie «la plupart du temps» vient parce que j'ai hérité de 2 systèmes qui font une tâche très similaire suite à une fusion d'entreprises.
Il est vraiment important que ces systèmes existants ne soient pas mis en danger car ils exécutent l'activité de la force de terrain pour l'entreprise et la panne = ligne de fond.
J'ai donc choisi d'utiliser Azure Service Bus pour synchroniser les deux bases de données sous-jacentes, ce qui semble correct à ce jour.
J'utilise les modifications publiées depuis ces Db hérités pour remplir/synchroniser une nouvelle instance Db. La nouvelle instance est destinée à être la consolidation de l'ancien monde dans un nouveau et je travaille très dur pour établir un modèle de domaine qui représente les activités de l'entreprise. C'est lent mais l'éducation fonctionne et la valeur en est vue.
Le 'nouveau système' aura également une nouvelle interface utilisateur, et nous avons décidé de la mettre en œuvre dans MVC. J'ai 2 gars en Inde qui vont construire cette application MVC, le reste arrivera ici à Londres.

Donc, voici le problème, j'aimerais que mon modèle de domaine soit lu par l'interface utilisateur via un service web. Ma motivation est de découpler et de protéger ce modèle des autres parties du système. L'utilisateur utilisera le service Web pour charger les données au démarrage, en publiant les modifications apportées au bus. Est-ce que les Indiens prennent les données renvoyées et conservent leur propre modèle de vue local ou quoi? À quoi devrait ressembler la plomberie? Il y a peut-être 80 instances d'interface utilisateur qui travaillent pendant la journée.

Le modèle de domaine est déjà clairement différent de la vue attendue sur les écrans.

J'apprécierais vraiment quelques conseils ici que j'ai une occasion rare de « faire les choses » .... :-) Cordialement Steve

Answer 1

1) Gardez le trafic interne de l'entreprise caché. 2) Exposez REST/SOAP/tout ce qui convient ici, à l'application MVC. 3) Cette application MVC peut être côté serveur, côté client, mobile, tout le temps. Mais il ne consomme que des API "publiques". 4) Construire serivce intermédiaire qui gérera les demandes de l'application MVC, et être en mesure de parler à d'autres parties de l'entreprise infra.

De cette façon, vous et votre équipe en Inde avez une liberté totale dans la conception de vos besoins. L'application MVC peut être exécutée à partir d'Internet (et pas derrière certains VPN, ou quelque chose de similaire). L'équipe en Inde ne connaît pas une seule chose à propos des internes d'autres systèmes (et vous n'avez pas besoin de connaître les internes de MVC). Etc.

En prime Vous aurez l'architecture prête pour l'ajout de différents clients (comme les applications mobiles) à l'avenir.