Composite UI for Service Oriented Systems – Challenges Part II

This blogpost is part of a larger blog post series. Get the overview of the content here.


Start early with an automated deployment. It will safe your ass! But try to keep it as simple as possible. If your deployment gets to complex this usually indicates that your “thing” decomposition is also too complex. Tools like Octopus Deploy or the Deployment Manager from Redgate help to visualize and monitor the deployment process to multiple environments. Keep in mind that managing the configuration files can be tricky and design for it from the beginning.


Frameworks like NServiceBus go for a fast and easy development story. Therefore NServiceBus favors interfaces and classes (POCOs) for contract sharing. Depending on the interoperability requirements of your system that can be problematic. So in that scenario favor loose contracts like JSON, XML… over interfaces and classes. But if you are a .NET shop why not leverage interfaces and classes as contracts? As long as they don’t have any behavior except simple validation and of course no third party dependencies this approach works pretty well. So be pragmatic! For queries, command senders or integration problems the easiest approach is when the IT/OPS defines consumer driven interfaces and the responsible “things” implement those interfaces. This can easily be solved with DI containers and dynamic module loading.


Composite UI in the .NET world can be hard. We just don’t have enough mature tools for example for multi-repository dependency management. Of course there is Nuget and tools like Ripple from Jeremy Miller and Josh Arnold. But as soon as you begin to divide your “things” into multiple repositories and try to get the dependency graph right, things can get hairy. Aim for the simplest approach the can possibly work and gradually evolve from there if necessary. For example use Semantic Versioning for your contracts and use Nuget packages and an internal nuget feed to manage the dependencies. But often the simplest approach is by having one solution and one repository for the entire system and one repository. If this doesn’t work split out separate “things” into separate repositories. Another approach is you simply work with Pull Request for the contracts. For example if additional contracts get added the “thing” which defined it sends pull requests to others.


We Developers get overly excited about composition. We want to build all sorts of fancy dynamic and convention based approaches to dynamically wire everything together. Sometimes approaches like that might fit but my experience is that those generic approaches fall apart pretty quickly. So don’t get overboard with fancy techniques and start simple. Sometimes hard wiring is just fine!

In summary we can say:

Do composition as high up as possible (preferably on the client) but you can only do composition on things you own.

That’s the last post of this series! Thanks for reading. Here a list of links you might find useful.

About the author

Daniel Marbach


Recent Posts