Estoy creando una lógica comercial en la aplicación, pero no estoy seguro de cómo o dónde encapsularla, he utilizado el patrón de repositorio para el acceso a los datos, he visto algunos proyectos que usan DDD que tiene algunas clases con el sufijo "Servicio" y el sufijo "administrador", ¿qué se supone que debe cuidar cada una de estas clases en DDD?Diseño impulsado por dominio: administrador y servicio
No se cuelgue demasiado en la nomenclatura; en general, los servicios brindan algo a las clases a fin de reducir el acoplamiento, y el administrador es aún más general; podría tratarse de una clase que realiza un seguimiento de otros objetos y/o estados.
Mucho más importante para un enfoque DDD es realmente modelar el dominio. Esto depende en gran medida de su sector (o de la industria a la que apunta su aplicación) y del tipo de aplicación que está creando. "¿Dónde encapsular?" es la fuerza impulsora básica en este proceso, pero en gran parte se reduce a crear representaciones de clase de entidades del mundo real: empleados, clientes, proveedores, facturas, transacciones, presupuestos, contratos, etc.
Los servicios y gerentes pueden ayudar pegue estas cosas juntas en el tiempo de ejecución, y esa nomenclatura ayuda a distinguir estas clases de cosas que encapsulan la lógica del dominio.
En un escenario en el que ha decidido utilizar el patrón de modelo de dominio (claramente si desea hacer DDD), la lógica empresarial como validaciones, cálculos y reglas de negocio definitivamente forma parte del modelo de dominio (sus objetos comerciales y relaciones en esto).
Una buena referencia general también podría darle el libro de Martin Fowlers 'Patterns of Enterprise Application Architecture'.
Trate de ser lo más específico posible con el nombre. Como regla general, yo llamaría avoid the name "Manager", ya que su significado es bastante vago.
Los actores/nombres lógicos de negocios típicos serían Validadores, Reglas, Proveedores, Supervisores, Importadores/Exportadores, Serializadores, Procesadores (procesar una transacción) y Repositorios (el último de los cuales ya tiene). Si una sola clase está realizando más de una de estas funciones, probablemente debería dividirse en subclases.
Usted hizo la pregunta, "¿de qué se ocupan estas clases?" y de hecho, ese es el punto. El nombre SomethingManager no le dice nada. OrderValidator, por otro lado, le dice muy claramente lo que hace la clase, al igual que CustomerHistoryExporter. Los servicios se encuentran en el área gris; si los servicios llevan el nombre de una acción pasiva, como ShippingService, entonces está bastante claro qué trata el servicio, pero un nombre mejor podría ser algo como ShipmentDispatcher. Usted consigue la idea, espero.
¡Una buena explicación, gracias! –