¿Debo organizar mis carpetas por dominio comercial o por dominio técnico?

Por ejemplo, si estoy usando una arquitectura similar a MVC, ¿qué estructura de carpetas debo usar?

domain1/
    controller
    model
    view
domain2/
    controller
    model
    view

O:

controllers/
    domain1
    domain2
models/
    domain1
    domain2
views/
    domain1
    domain2

Deliberadamente omití las extensiones de archivo para mantener esta pregunta independiente del idioma.

Personalmente, preferiría separarme por dominio comercial (intuición), pero veo que la mayoría / muchos marcos se separan por dominio técnico. ¿Por qué debería elegir uno sobre el otro?

Creo que esto depende de un proyecto específico.

Por ejemplo, si los diferentes dominios comerciales son totalmente independientes entre sí, entonces me organizaría por dominio comercial.

Pero si hay un código compartido entre los dominios comerciales, o más bien, los dominios comerciales son diferentes variantes de la misma base de código, entonces parece más lógico organizar por dominio técnico. Y si usa algún tipo de lenguaje orientado a objetos, entonces probablemente pueda subclasificar sus controladores genéricos, modelos, etc. en sus archivos específicos de la empresa para hacerlos más delgados.

También hay un punto intermedio (dorado) entre los dos: elimina el código compartido en su propio dominio y úsalo en otros dominios. Esto le brinda un diseño inteligente, pero permite el código compartido entre dominios comerciales.

Domain1              # This domain changes bits of standard MVC code
  controllers
  models
  views
Domain2              # this domain only modifies views, all else is standard
  views
Shared               # Here is the better part of code base
  controllers
  models
  views

PD. Creo que la mayoría de los marcos se organizan por dominio técnico solo porque tienden a esperar que mezcle diferentes dominios de negocios en un solo proyecto solo si ha compartido código y de lo contrario crearía proyectos separados.

EDITAR:

Por ejemplo, supongamos que hay una aplicación web que maneja el almacén de una empresa. En forma genérica, esto podría aplicarse a muchas empresas, pero cada una de ellas puede tener algunos detalles que no se cumplen y les prohíbe comprar. para organizar elementos en tres niveles en lugar del valor predeterminado de dos.

Por supuesto, podría bifurcar el proyecto para cada una de estas empresas. Pero si el marco / lenguaje lo permite, puede usar subclases o complementos, etc. para personalizar partes del proyecto genérico según las necesidades de cada cliente y organizarlas en los diseños de Business Domain.

Por ejemplo, si el proyecto genérico exporta a JSON solo el artículo en sí, Domain1 puede subclasificar el controlador y hacer que también exporte problemas de entrega recientes.

Y si luego descubre que el Dominio1 tiene un componente que también es válido para el Dominio2, puede extraer una versión genérica de este a Compartido.

Como dijiste, muchos frameworks se organizan por dominio técnico y eso es lo que he usado por ahora, solo porque mi FW de elección lo hace más fácil. Pero con un poco (o mucha) grasa de codo, creo que podría reescribir las rutas de inclusión para admitir también el diseño de Business Domain.

Creo que es esclarecedor preguntar, "¿qué es más probable que agregue regularmente, más dominios o más divisiones técnicas?" Entonces, sea cual sea la respuesta, colóquela en el nivel superior.

En la mayoría de los casos, su arquitectura técnica se solidificará más rápido que su dominio. Eso significa que primero debe organizarse por dominio, luego por componente arquitectónico. La razón es que cuando algo en un dominio cambia, es posible que tenga que agregar o cambiar múltiples componentes técnicos en ese dominio, pero es de esperar que esté localizado y no se extienda demasiado a otros dominios.

Si cambió su marco de GUI, eso significa que sus cambios se extenderán por toda la aplicación, pero nuevamente, rara vez cambia su marco de GUI, pero siempre está cambiando la lógica de su dominio.

Mantenga las cosas juntas si es probable que cambien al mismo tiempo.

Hay otra alternativa y es mover las partes separadas en complementos. CakePHP hace eso, por ejemplo. Le permitirá generar partes MVC completas que son reutilizables y que puede ordenar según la lógica que desee.

Su aplicación principal solo los usará y vinculará a ellos.

Básicamente su pregunta también es sobre cohesión y acoplamiento. Desea que las partes separadas funcionen de la manera más independiente posible. De esa forma, obtienes código comprobable y reutilizable.

Teniendo eso en cuenta: si se divide por dominio, ¿cómo reutilizaría partes de su aplicación? Por ejemplo, tome una tienda web: aparece una solicitud para / orders / view / 1, por lo que debe mostrar el número de pedido. 1. Vaya a / orders / controllers / order_controller. Si separó el dominio por productos y pedidos, ya necesitaría partes del otro "dominio".

Allí puede comenzar a interconectar cosas, pero es probable que las cosas en la mayoría de los negocios sean demasiado coherentes. Si tomas el enfoque técnico. Por ejemplo, podría tener un complemento manejando las órdenes. Pones objetos de Producto desde tu aplicación central. De esa manera, puede probar el complemento fácilmente, simplemente cree algún objeto de Producto con un nombre y precio y envíelo.

El complemento hará exactamente lo que debe hacer. Dependerá de su entrada y no de otras "partes / dominios / áreas".

Microsoft ASP.Net MVC 3 tiene el concepto de "Áreas". Cuando introduce "Áreas" en su proyecto MVC, lo dividen así:

area1/
   models
   views
   controllers
area2/
   models
   views
   controllers

Encontré que esto es bastante natural. Un área es una "gran parte" de un proyecto, y trabajar en una unidad autónoma tiene mucho sentido.

Utilizamos espacios de nombres para que coincidan, FWIW.

Desde mi experiencia personal con una tienda web que consta de 300 000 líneas de código, siempre iría a organizar por dominio comercial. De esta manera, no solo puede obtener una visión general rápida de todas las clases relevantes cuando trabaja en un área funcional, en Java también puede hacer uso de la visibilidad del paquete.

Algunos detalles para aquellos que estén interesados: cuando el proyecto se inició hace 5 años, los desarrolladores crearon la siguiente estructura de paquete:

com
  example
    web
      struts
        action
        form
      shared
      functionality1
      functionality2

Cada función de la tienda, como el carrito de compras, la búsqueda de productos, etc. consta de varias acciones, cada una con su propia clase de formulario (estructura ordenada por el marco MVC). Terminamos con más de 200 clases en el paquete de acción, cada una completamente separada de su clase de formulario asociada. Lo peor es que las acciones no implementan demasiada lógica, sino que llaman a servicios específicos de funciones que residen en otro paquete.

Sugerí y convencí al equipo de que deberíamos cambiar a organizar paquetes por dominio comercial. El razonamiento es simple: si realmente desea ver una lista de todas las acciones, simplemente puede abrir la vista de jerarquía de tipos de cualquier IDE decente. Sin embargo, lo que el IDE no puede hacer es inferir el dominio comercial al que pertenece una clase. Además, ese enfoque le permite hacer públicas solo aquellas clases que son necesarias para varias funcionalidades, manteniendo el resto en la visibilidad del paquete.

Estoy de acuerdo en que muchos marcos se separan por dominio técnico, por lo que a menudo empiezo de esta manera cuando uso un nuevo marco. Sin embargo, consistentemente uso el dominio comercial como el nivel principal de la organización de carpetas.

Personalmente, creo que es mucho más fácil mantener mi Controlador Foo y el Repositorio Foo o lo que sea juntos que ir y venir entre la carpeta del Controlador y la carpeta del Repositorio, ya que a menudo necesito trabajar en ambos al agregar características alrededor de Foo. En proyectos más grandes, esto es aún más importante ya que la distancia entre las carpetas técnicas puede ser grande y convertirse en una pérdida de tiempo notable durante el desarrollo.