Lo que @Kurro Lopez te ha presentado con detalle es lo que te decía en la primera respuesta:

También podría estar todo junto si no hay solapamiento entre nombres de paquetes y clases.

Como ellos ya lo han hecho han elegido la forma que mejor les ha funcionado. Por lo que desde luego es una buena solución.

El uso de mapeo de paquetes es util para no tener que duplicar clases (y código) en diferentes Namespaces. Pero es un mecanismo asociado a la operación/despliegue pero no al desarrollo. Son cuestiones diferentes. Puedo desarrollar un paquete de forma común y luego repartirlo entre varios namespaces (como una librería) o puedo ponerlo en un lugar accesible por varios (aka mapeo). Pero lo haga de una manera o de otra no me afecta a como lo desarrollo.

Sí claro, eso tiene mucho sentido. Lo único es que os toca gestionar varios Repos. Pero será muy práctico ir identificando funcionalidad común y llevarlo  al Repo común. Luego las clases comunes gestionarlos como librerías independientes. Si el esquema que tenéis se despliega todo en la misma instancia entonces también podéis hacer mapeos de clases entre Namespaces.

Hola Jorge, 

Me surgen varias dudas. Si trabajáis con diferentes Namespaces es porque son proyectos diferentes o ¿cómo están relacionados?. En principio lo lógico es que cada Namespace disponga de un Repo diferente. También podría estar todo junto si no hay solapamiento entre nombres de paquetes y clases. Ya que la idea es que cada desarrollador tenga un entorno aislado y por lo tanto el que toque clases de un Namespace normalmente no tocará las otras y esas no molestan. Sin embargo es muy importante que los despliegues en el servidor en producción se hagan de manera controlada y mediante paquetes de despliegue que se construyan ex-profeso para el mismo. No se si me he explicado bien...

Pero en resumen, una cosa es como se organiza el código en el desarrollo y otra diferente es como repartas las clases en el despliegue

Hola,

Gracias por preguntar. 

Por lo que veo me parece que esto es un mensaje de MONMGR. Si es así este mensaje es generado por el Core y no por la para de Interoperabilidad así que ahora mismo el mecanismo es solo correo. Pero se me ocurre que pueden utilizar un servicio de lectura de correo y generar una alerta (Ens.Alert) que puedan manipular a su criterio. Aunque claro siendo una advertencia del correo es posible que haya procesos que se paren.

Hola @Yunier Gonzalez hay varias opciones. Una es hacer como dices un Backup/Restore de la BD para "jugar" con una imagen sin perjudicar los datos reales. Otra cosa que se puede hacer es utilizar un Shadow. Un Shadow replica todo lo que sucede en una BD a otra BD en otra instancia mediante el uso del journal. De esta forma tienes datos "casi" en tiempo real. En el caso de un Mirror se puede usar una replicación asíncrona para uso como Reporting.