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

Neem geen logica op in de description voor het samenstellen van de inhoud van een property #92

Open
melsk-r opened this issue May 27, 2021 · 6 comments
Assignees
Labels
Design Rule Bespreekpunten om al dan niet op te nemen in de VNG-Design Rules

Comments

@melsk-r
Copy link
Contributor

melsk-r commented May 27, 2021

In de description van een property mag geen logica (algoritme) worden beschreven voor het samenstellen van de inhoud van het property.

Ratio: Opnemen van providerlogica veroorzaakt tight coupling tussen de bron-implementatie en de API.

@melsk-r melsk-r added the Design Rule Bespreekpunten om al dan niet op te nemen in de VNG-Design Rules label May 27, 2021
@melsk-r
Copy link
Contributor Author

melsk-r commented May 27, 2021

JBo: Overnemen
HK:
RM: Overnemen
MV: Overnemen
GJ: Overnemen
JBi: Overnemen

JBo : Aanvullen dat de betreffende logica opgenomen moet worden in de functionele specificaties (feature-files?)
MV: Is tight-coupling dan verkeerd? Het hangt volgens mij af van het soort API. Een systeem of proces API (zoals ZGW) zal misschien wel een algoritme bevatten, een experience API zoals HC niet.
JBi: In aansluiting/reactie op MV. Een API mag toch best algoritmiek definiëren? Alleen moet je deze niet in de omschrijving van een property stoppen maar in een aanvullende specificatie.
MV: Logica moet beschreven staan in de aanvullende specificaties.

@JohanBoer
Copy link
Collaborator

@michielverhoef en @HenriKorver, Willen jullie hier ook je advies toevoegen ? De rest is het met elkaar eens. Als jullie op dezelfde lijn zitten kan deze worden opgenomen in onze design rule lijst.

@michielverhoef
Copy link
Contributor

Mee eens. Dan zou ik in de omschrijving wel iets opnemen waaruit blijkt dat de te volgen logica beschreven staat in de aanvullende specificatie. Ook om te voorkomen dat ontwikkelaars zonder meer de OAS gebruiken om code te genereren en niet verder kijken. Ja, dat is bedrijfsrisico maar dan hebben we het in ieder geval aangegeven.

@HenriKorver
Copy link
Collaborator

Kan iemand een (paar) voorbeeldje(s) geven? Ik weet namelijk niet zeker of ik de design rule goed begrijp. En zelfs al zou ik het ermee eens zijn dan moet de rule ook voor anderen duidelijk zijn...

@melsk-r
Copy link
Contributor Author

melsk-r commented Jun 25, 2021

Mee eens. Dan zou ik in de omschrijving wel iets opnemen waaruit blijkt dat de te volgen logica beschreven staat in de aanvullende specificatie. Ook om te voorkomen dat ontwikkelaars zonder meer de OAS gebruiken om code te genereren en niet verder kijken. Ja, dat is bedrijfsrisico maar dan hebben we het in ieder geval aangegeven.

Moet ik dit interpreteren als een 'MV: Overnemen' of is het een antwoord op de opmerking van JBi?

@michielverhoef
Copy link
Contributor

Moet ik dit interpreteren als een 'MV: Overnemen' of is het een antwoord op de opmerking van JBi?

Beide :-) Dus geen logica in de OAS maar wel een opmerking dat deze logica beschreven staat in de aanvullende specificaties.

JBo: Overnemen
HK:
RM: Overnemen
MV: Overnemen
GJ: Overnemen
JBi: Overneme

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Rule Bespreekpunten om al dan niet op te nemen in de VNG-Design Rules
Projects
None yet
Development

No branches or pull requests

4 participants