¿Es esta una buena estructura de solución de Visual Studio para un servicio web RESTful de diseño basado en dominio?

Navega tus respuestas
14

Estoy creando una solución RESTful de la API Web C # .NET 4.5 y me gustaría que alguien me dijera si la solución de mi proyecto es correcta y / o inteligente (¿suficiente?) para una solución diseñada con el diseño impulsado por dominio, por favor.

La solución se ha dividido en 6 proyectos:

  • / Base

(No referenciado por nada)

El proyecto web forma la interfaz entre la solución y el mundo exterior. Contiene los controladores web API. Casi no contiene lógica más allá de la recopilación de valores de los objetos de solicitud y la solicitud de trabajo a la capa de BizApi.

  • /Biz.Api

(Referenciado por Base))

Proporciona los servicios de dominio y permite que el proyecto de interfaz / Base tenga acceso a los objetos de lógica de negocios del dominio en el proyecto /Biz.Domain.

  • /Biz.Domain

(referenciado por Biz.Api)

Proporciona las clases de dominio para la capa Biz.Api. Estos proporcionan métodos para manipular los datos de la empresa en la memoria.

  • /Dal.Db

(referenciado por Biz.Api)

La capa de repositorio de la base de datos. Accede a las bases de datos y asigna datos devueltos en DTO internos definidos en la capa / Interfaces.

  • /Dal.Services

(referenciado por Biz.Api)

Proporciona una capa proxy para dependencias externas como servicios web y asigna los datos devueltos a DTO internos definidos en el proyecto / Interfaces.

  • / Interfaces

(referenciado por la mayoría de los proyectos anteriores)

Contiene las clases DTO para pasar datos alrededor de la solución y las interfaces C # para definir contratos para cosas como IoC.

    
pregunta Matt W 10.09.2014 - 14:22

2 respuestas

19

Esta estructura de carpetas está inspirada en el famoso Implementando el diseño impulsado por dominio por Vaugh Vernon.

Solución:
├ WebService (los servicios REST residen aquí)
├ WebServiceTests
├ Aplicación (los servicios de aplicación residen aquí)
├ ApplicationTests
├ Dominio (Entidades, VO, Servicios de dominio, fábricas de dominios, especificaciones, eventos de dominio, interfaces de repositorios, interfaces de servicios de infraestructura)
├ Pruebas de dominio
├ Infraestructura (Repositorios, Implementación de servicios de infraestructura, Adaptadores a servicios externos)
└ Pruebas de infraestructura

Comienzo con una solución, luego creo cuatro proyectos para cada capa en mi aplicación y luego otros cuatro proyectos para cada prueba de capa.

No cree una carpeta interfaces o services en su capa de dominio; en lugar de eso, las clases relacionadas deben agruparse por funcionalidad en los módulos.

    
respondido por el Songo 10.09.2014 - 23:22
1

En cuanto a la estructura, me parece bien, aunque hubiera encontrado nombres diferentes, más auto-descriptivos, como "YourProjectWebApi" en lugar de "Base" , "Dal.External" en lugar de "Dal.Services" y así en.

Sin embargo, puede haber un olor en la parte "DTO interna", ya que se supone que debes sacar las entidades de los repositorios y poder tomar acciones de dominio (negocios) directamente sobre ellas. Las entidades no son solo DTO.

Reconozco que Dal.Db no depende de Biz.Domain, de que la capa de dominio está realizando una asignación entre los DTO del proyecto Interfaces (¿devueltos por Repositories?) y sus propios objetos de dominio. Esto no sería correcto en una arquitectura DDD típica del estado de la técnica (== "cebolla" o "hexagonal"): la capa de dominio no debe hacer referencia a otros proyectos. Por el mismo motivo, las interfaces del repositorio deben declararse en el dominio y no en Interfaces como supongo.

    
respondido por el guillaume31 11.09.2014 - 11:43

Lea otras preguntas en las etiquetas

¿Qué es un argumento de salida, como se menciona en el Código de limpieza de Martin? Beneficios de tarifa por hora para el cliente [cerrado]