Es una Territory card transversal. Atraviesa todas las capas y agrupa su contenido alrededor de un Aggregate root.
Especificaciones
Al ser una Territory card, tiene una complejidad de 0.
Su misión principal… se encarga de representar un aspecto del Domain dentro de un Bounded context.
Como características más concretas a comentar. Podemos decir que es una porción del dominio que representa un aspecto específico del dominio, encapsulando lógica de negocio y entidades.
Al ser transversal, se relaciona con todos los elementos, ya que es un contenedor que abarca todas las capas de un Bounded context de manera vertical.
Mientras que el concepto de Clean Architecture como tal está centrado en la división de un Bounded context en capas (a.k.a. Package by layer), a veces el desarrollo crece y puede no ser suficiente.
El concepto de Module está pensado para aportar más contexto al Bounded context, agregando una granularidad extra. En el libro de Clean Architecture de Robert C Martin, se hace referencia al concepto de screaming architecture y agrega la opción de hacer un Vertical slicing, haciendo uso del concepto de Package by feature o Package by component.
Package by Component (Paquete por Componente):
En elfoque de paquete por componente fomenta la creación de componentes reutilizables e independientes con un fuerte énfasis en visualizar la arquitectura.
Package by Feature (Paquete por Funcionalidad):
En este enfoque, el código se organiza según las características o funcionalidades del sistema. Cada característica o módulo tiene su propio paquete o directorio, y todas las clases, módulos o componentes relacionados necesarios para esa característica se agrupan dentro de ese paquete. Este enfoque enfatiza la organización del código de una manera que refleje las características orientadas al usuario de la aplicación.
Qué criterio escoger para segmentar el Bounded context en Modules
Usar el concepto de Package by Feature busca crear una estructura de código clara y fácilmente comprensible. La elección depende de las necesidades y objetivos específicos del proyecto. Algunos proyectos pueden beneficiarse más de organizar el código según las características, mientras que otros pueden encontrar más adecuado organizar el código según componentes técnicos. La clave es hacer que la arquitectura del sistema “grite” su propósito y funcionalidad.
En un mundo ideal, un Aggregate root puede ser un buen punto de partida, pero se ha de estudiar en cada caso.
En el libro de Domain-Driven Design escrito por Eric Evans hace referencia a los conceptos de Low Coupling e High Cohesion, lo que se traduce en que cada módulo debe ser independiente de otros módulos del sistema. Y a su vez, todos los componentes del módulo están relacionados, lo que facilita la comprensión de lo que hace el módulo como un subsistema autónomo, ya que cada módulo debe centrarse en una idea/responsabilidad.
Para profundizar más…
Domain-Driven Design: Chapter 5 - A Model Expressed in Software - Modules
Clean architecture: Chapter 34 - The missing chapter - Package by feature