Naming e Ubiquitous Language in DDD

1

Stiamo discutendo con i colleghi su come denominare un metodo:

ProcessInstructions vs ProcessInstructionsHavingDeliveryInProgrssStatus

Coloro che insistono sul nome dicono che è più generico e non rivela l'implementazione interna. Inoltre, il secondo nome è davvero scomodo.

L'altra metà preferisce il secondo nome. Nonostante sia lungo (e brutto) indica chiaramente le aspettative del business. L'elaborazione è disponibile solo per le istruzioni su quale stato è DeliveryInProgress .

Quindi, in sostanza, la disputa riguarda il tipo di informazioni che dovrebbero o non dovrebbero essere rivelate dai nomi. Contracts should be stable rispetto a Contracts should be continuously refactored to reflect domain .

Entrambi gli approcci sembrano avere uguale importanza.

Che cosa dice DDD su questo?

    
posta Pavel Voronin 09.09.2016 - 11:22
fonte

1 risposta

1

DDD ti dice di definire la lingua del tuo business.

Non posso credere che qualcuno dica

"Process the instructions (on this order?) which require the delivery to be in progress!"

sicuramente direbbero:

"Process the instructions!"

"We can't, the delivery is not in progress"

In realtà, sono anche riuscito a chiedermi se qualcuno avrebbe detto "Elabora queste istruzioni!" del tutto, sembra così generico. sicuramente direbbero: (assumiamo che tu stia parlando di ordini e tracciamento)

"Update the tracking information on the order!"

"we cant! its not out for delivery yet!"

quindi avresti

/// <exception cref="NotOutForDelivery">Thrown when order isnt out for delivery</exception>
Order.UpdateTrackingInformation()

O forse una volta che un ordine è "in consegna", si chiama invece una consegna? allora avresti la segregazione dell'interfaccia che vuoi

var delivery = Order.Send()
delivery.UpdateTrackingInfo(trackinginfo)
    
risposta data 09.09.2016 - 11:38
fonte

Leggi altre domande sui tag