IoC versus Observable revisited

Deze week kwam er weer een oude vertrouwde discussie langs: IoC versus Observable. Mijn collega Ralf Wolter heeft hier een tijd terug al eens een inspirerende blogpost over geschreven: Liever geen Inversion of Control.

Het argument dat deze keer naar voren kwam was dat een observable toch kennis moest hebben van het contract dat naar buiten toe aangeboden wordt, net als bij IoC. Mochten er dus observers aangesloten worden die aanvullende informatie nodig hebben moeten de contracten uitgebreid worden. Dit contract kan je dan als interface net zo goed opnemen in het observable object en dan met een IoC framework laten injecteren.

Modelleertechnisch is er inderdaad geen verschil. Kennis van het contract dient ook aanwezig te zijn in de observable klasse die het event opgooit, dus deze kan net zo goed worden vervangen door een interface. Het technische verschil dat er in mijn optiek wel in zit is dat een interface slechts één implementatie ondersteunt, en dat een observable in principe oneindig veel observers ondersteunt. Dit maakt aan de observer kant dat je opdeling kunt hebben en niet alles in één grote interface implementatie hoeft te vervatten. Bij IoC zal je zowel de aangesloten emailcomponent als de databasecomponent moeten aanspreken via deze ene implementatie. Bij observable kan je ze flexibel aan- en afkoppelen.

Blijft het moeilijke punt: ik krijg een nieuwe requirement die vereist dat ik bepaalde gebeurtenissen in mijn systeem wil gaan uitsturen via emails bijvoorbeeld. Dit is een punt dat pleit voor het correct ontwerpen van je observable classes; alle voor de business significante user stories moeten enerzijds vanuit de buitenwereld aangeroepen kunnen worden op deze classes (via een service layer of iets dergelijks), maar andersom moeten ze dus óók alle relevante business events publiceren via hun observable hooks. Dit gaat dus verder dan alleen CRUD-achtige zaken voor repositories bijvoorbeeld. Sterker nog: wellicht dat CRUD helemaal niet de standaard modus moet zijn voor deze observable classes, dus géén ObjectChanged, ObjecstRequested events meer maar domeinspecifieke zoals QuestionnaireCompleted of EmployeeRetired events…?