Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IRestCollection : better naming #208

Open
Poltuu opened this issue Oct 11, 2018 · 4 comments
Open

IRestCollection : better naming #208

Poltuu opened this issue Oct 11, 2018 · 4 comments

Comments

@Poltuu
Copy link
Contributor

Poltuu commented Oct 11, 2018

L'apparition du terme REST dans le domain est en effet assez surprenant. Peut-on trouver un meilleur nom ?

@rducom
Copy link
Contributor

rducom commented Oct 11, 2018

Le terme Services est un terme largement utilisé dans toute la littérature RDD.
Il me semble d'autant plus pertinent que la couche actuelle RestCollection a vocation à implémenter le métier.
L’existence du terme "service" dans le SOA pourrait préter à confusion, MAIS le terme est à la base du DDD, donc autant le réutiliser pour le sens qu'il porte dans un contexte DDD, et charge à nous de clairement expliquer le sens DDD du mot service.

@nfaugout-lucca
Copy link
Contributor

Pour ma part je préférerais qu'on garde Service pour justement tous les services qui ne gèrent pas des entités, pour faire la distinction au premier coup d'oeil.

On pourrait simplement renommer IRestCollection en IEntityCollection du coup = une collection qui gère des entités.

C'est lié à l'autre Issue, mais si on vire la classe EntityBase, dont le base faisait référence au fait que c'était une super classe, on pourrait renommer IEntityBase en IEntity tout court, et ainsi donner encore plus de sens à IEntityCollection.

@rducom
Copy link
Contributor

rducom commented Oct 11, 2018

C'est dommage de pas reprendre la terminologie DDD pour Services

qu'on garde Service pour justement tous les services qui ne gèrent pas des entités

Peux-tu donner des exemples ? je ne vois pas à quoi tu fait référence

@nfaugout-lucca
Copy link
Contributor

Je n'ai trouvé aucun exemple dans Lucca.Faces ou Lucca.Auth, parce que tout le code métier du Domain est encapsulé dans des collections et les entités liées.

Mais j'ai trouvé un exemple dans Poplee.Talent : https://github.com/LuccaSA/Poplee.Talent/blob/rc/back/Poplee.Talent.Domain/Reviews/Services/ReviewsPreparer.cs

C'est plus un Helper, mais ce service pourrait dépendre de plusieurs collections pour faire son traitement.

De manière générale, je te laisse regarder partout où y'a le terme "service" dans Poplee.Talent, tu verras qu'il y a papa/maman :'(

Donc si on ouvre la porte à mettre aussi des "services" pour gérer les entités, pour moi c'est la fin de la "bonne" organisation des projets.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants