¿Cómo se denominan las interfaces de repositorio y servicio y sus clases de implementación?¿Cómo nombrar las interfaces de repositorio y servicio?
Por ejemplo, tengo un modelo con el nombre Question. ¿Cuál sería el nombre del repositorio (interfaz e implementación) y el servicio (interfaz/implementación)?
Después de leer estos mensajes: Java Interfaces/Implementation naming convention y Interface naming in Java que reconsiderar lo que ya había hecho :)
Creo que hay dos aproximaciones para nombrar en DDD:
1) Basado en estereotipo. Aquí es donde incluyes el estereotipo de clase en su nombre. Por ejemplo:
QuestionsRepository, TaxCalculatingService etc
2) Basado en dominio. En este enfoque, solo usa el lenguaje de dominio y omite cualquier estereotipo en los nombres de clase. Por ejemplo:
Questions (or AllQuestions), TaxCalculator etc.
clases de implementación serían nombrados como SqlQuestions o InMemoryQuestions.
Intenté ambas opciones, pero ahora prefiero la segunda opción, ya que parece estar más alineada con la mentalidad DDD. Parece más legible y tiene una mejor relación señal/ruido. Lo que sigue es una cita de un great article en los repositorios por Phil Calçado:
El concepto de un repositorio como una lista de los objetos no es demasiado difícil de entender, pero es muy común para aquellas clases que terminan con métodos que son no relacionado con listas en absoluto.
Después de entrenar a muchos equipos en la adopción de un lenguaje ubicuo y patrones relacionados, descubrí que la mejor manera de hacer que la gente recuerde que los repositorios no son clases DAO comienza con la forma en que los nombra.
Hace años, Rodrigo Yoshima me contó sobre su convención al nombrar Repositorios. En lugar del estilo de nombres más comunes se muestran a continuación:
class OrderRepository {
List<Order> getOrdersFor(Account a){...}
}
promueve esto:
class AllOrders {
List<Order> belongingTo(Account a){...}
}
Se ve como un cambio pequeño pero ayuda mucho ...
Todo el artículo bien vale la pena leerlo y marcarlo.
Yo personalmente uso FooService, FooServiceImpl, FooRepository y FooRepositoryImpl.
Se podría argumentar que la Impl sufijo es el ruido, pero
FirstFooService y SecondFooServiceFooXxxImpl tipos se utilizan en ninguna parte del código, excepto en las pruebas unitarias : las dependencias se inyectan, y su tipo es la interfazUso 'FooDao' en lugar de' FooRepository' porque es más corto para escribir :) – Paul
No veo la necesidad de la interfaz FooService ya que solo tiene una implementación. El propósito de la interfaz es modelar objeto/componente que probablemente tendrá más implementaciones. Como validationRule, algún patrón de estrategia. Personalmente creo que hay una gran cantidad de uso excesivo de interfaz. Además, el hecho de que tenga Impl sufix como su implementación me dice que su implementación no es de ninguna manera específica. El nombre de implementación debe contener detalles de implementación. Por ejemplo, List, LinkedList, ArrayList. Sé que este enfoque es común, pero eso no significa que sea bueno. – Vajda
Ya no uso interfaces. Recuerde que esta es una respuesta a partir de 2012. Los marcos y los marcos burlones han evolucionado desde entonces. –
Sé que esto puede ser un detalle menor, pero ¿la clase implementadora debe tener un sufijo o prefijo? SQLAllQuestions o AllQuestionsSQL? ¿Qué prefieres? – LuckyLuke
Yo personalmente usaría SqlAllQuestions, pero no veo ninguna razón para no usar AllQuestionsSql, podría ser incluso mejor. Como dices, realmente no importa porque este nombre solo se usaría en una parte de la raíz de la composición de tu aplicación y no lo verías demasiado (http://blog.ploeh.dk/2011/07/28/ CompositionRoot.aspx) – Dmitry
Una cosa más. Leí su enlace y fue genial, pero ¿qué hace cuando tiene la interfaz AllQuestions y desea hacer una lista de todas las preguntas? AllQuestions.everything()? ¿Hay alguna convención o algo al hacer CRUD? – LuckyLuke