Arquitectura de bajo acoplamiento

Pensar una arquitectura de bajo acoplamiento
Para esto podemos dividir la aplicación en varios componentes, hacer referencia a los contratos (interfaces) y no a las implementaciones y asignarle sólo una responsabilidad a cada componente. Esto nos permitirá cambiar la implementación de dicho componente sin afectar los otros.

Por ejemplo DAOs tiene la responsabilidad del acceso a datos, no representa las entidades del dominio (que es responsabilidad de BEs), no tiene lógica de negocio (que es responsabilidad de Models), sólo se encarga de la persistencia de nuestro dominio (BEs). Quienes usan los DAOs, en realidad hacen referencia al contrato de DAOs, no a su implementación.

Arquitectura de nuestro ejemplo
Nuestro ejemplo se divide en tres grupos: Testing, Core e Implementations.
Grupo Testing:
Aquí están los test de nuestra aplicación, podríamos decir que estos tests son los que definen qué hace la aplicación en un modo verificable. Sólo podemos asegurar que funcione correctamente aquella característica que tenga su correspondiente test.
Los tests se dividen en tests unitarios (como Models.Testing) y tests de comportamiento o integración (como Integration.Testing).

Grupo Core:
- BEs: son las entidades que representan nuestro dominio.
- DTOs: son objetos serializables para la transferencia de información entre capas (físicas).
- DAOs: es el contrato que debe cumplir cualquier implementación de acceso a datos.
- Mappers: es el contrato que debe cumplir un conversor de BE a DTO y de DTO a BE.
- Models: es el contrato que debe cumplir cualquier implementación de lógica de negocios.
- Services: es el contrato que debe cumplir cualquier implementación de servicios de nuestra aplicación.

Como podemos ver, en el core de nuestra aplicación tenemos las definiciones de los componentes y no la lógica de los mismos (implementaciones). Aquí definimos los límites entre las piezas de nuestra aplicación y no cómo se va a resolver cada problemática en particular. Ésto nos permitirá cambiar las implementaciones cuando encontremos mejores alternativas.

Grupo Implementations:
Aquí encontramos las implementaciones de cada contrato, al momento de redactar este articulo hay una de cada uno. La implementación de Mappers está dividido en dos proyectos, uno implementa la transformación de DTO a BE (Mappers.AutoMapper) y otra de BE a DTO (Mappers.Reload).

Como podemos ver en el diagrama, las implementaciones sólo conocen los contratos de los otros componentes, esto es lo que nos va a garantizar que hay un bajo acoplamiento.