tl; dr: rompe las reglas si es necesario. DDD no puede resolver todos los problemas; de hecho, las ideas de objetos que ofrece son buenos consejos y un buen comienzo, pero son realmente malas elecciones para algunos problemas comerciales. Considéralo una pista sobre cómo hacer las cosas.
Para el problema de cargar todos los elementos secundarios (transacción) con el elemento primario (cuenta): Parece que te has encontrado con el problema n + 1 (algo en google) que muchos ORM han resuelto.
Puede resolverlo cargando de forma diferida los elementos secundarios (transacción), solo cuando sea necesario.
Pero parece que ya lo sabes al mencionar que puedes usar un TransactionRepository para resolver el problema.
Para 'ocultar' esos datos de modo que solo Account pueda usarlos, ni siquiera necesitaría almacenarlos donde nadie más podría deserializarlos, como una tabla relacional pública. Podría tenerlo almacenado con el 'documento' de la cuenta en una base de datos de documentos. De cualquier manera, si alguien se esforzara lo suficiente, aún podría ver los datos. Y 'trabajar' con eso. Y cuando no estás mirando, ¡lo harán!
Por lo tanto, puede configurar permisos, pero luego, debe ejecutar 'cuenta' como un proceso separado.
De lo que realmente se da cuenta aquí es que DDD y el uso puro del modelo de objetos a veces lo llevarán a una esquina. A decir verdad, no tiene que usar la raíz de 'composición' / agregado para beneficiarse de los principios de diseño de DDD. Es solo una cosa que puede usar cuando tiene una situación que se ajusta a sus limitaciones.
Alguien puede decir 'no optimices temprano'. Sin embargo, aquí, en este caso, conoce la respuesta: habrá suficientes transacciones para atascar un método que los mantendrá a todos para siempre con la cuenta.
La verdadera respuesta es comenzar a ponerse de pie SOA. En mi lugar de trabajo vimos los videos de 'Computación distribuida' de Udi Dahan y compramos nServiceBus (solo nuestra elección). Haga un servicio para cuentas: con su propio proceso, colas de mensajes, acceso a una base de datos de relaciones que solo él puede ver, y ... viola, podría codificar sentencias SQL en el programa e incluso incluir un par de scripts de transacción de Cobol (broma por supuesto), pero en serio tienen más separación de preocupaciones de lo que el snob más inteligente de OO / Java jamás podría soñar.
Recomiendo modelarlo bien de todos modos; Puede obtener los beneficios de la raíz agregada aquí sin los problemas si trata el servicio como un mini-texto delimitado.
Esto tiene un inconveniente, por supuesto. No puede simplemente RPC (servicio web, SOAP o REST) dentro y fuera de los servicios y entre ellos o puede obtener un antipatrón SOA llamado 'el nudo' debido al acoplamiento temporal. Debe usar la inversión del patrón de comunicación, también conocido como 'Pub-Sub', que es similar a los manejadores de eventos y los eventos que generan eventos, pero (1) entre procesos (que puede colocar en máquinas separadas si se sobrecargan en una).
El problema real es que no desea un servicio que necesita obtener datos de otro servicio para 'bloquear' o esperar: debe disparar y olvidar el mensaje y dejar que un controlador en otra parte de su programa lo recoja para completar el procesamiento. Esto significa que tienes que hacer tu lógica de manera diferente. nServicebus automatiza el patrón de 'saga' para ayudar con algo de esto, pero al final, debe desarrollar un estilo de codificación diferente. Todavía puede hacerlo todo, ¡solo tiene que hacerlo de manera diferente!
El libro "Patrones SOA" de Arnon Rotem-Gal-Oz responde muchas preguntas sobre esto. Incluyendo el uso del 'patrón de servicio activo' para replicar periódicamente datos de servicios externos a los suyos cuando surja la necesidad (se necesitarían muchos RPC, o el enlace no es confiable / no está en el ecosistema de publicación / suscripción).
Sólo para previsualización, interfaces de usuario qué tienen que RPC en los servicios. Los informes se generan a partir de una base de datos de informes alimentada por las bases de datos de los servicios. Algunas personas dicen que no se necesitan informes y que el problema debe resolverse de otra manera. Sé escéptico de esa charla.
Al final, sin embargo, no todas las cosas se pueden clasificar adecuadamente en un solo servicio. ¡El mundo no funciona con código de raviolis! Entonces tendrás que romper las reglas. Incluso si nunca tuviera que hacerlo, los nuevos desarrolladores del proyecto lo harán cuando lo deje. Pero no se preocupe, si hace lo que puede, el 85% que sigue las reglas hará que un programa sea mucho más fácil de mantener.
Wow, eso fue largo.