Scope

The scope of what we attempting is crazy. Once again i'm going to talk out my thought process to make sense of what's going on.

We are building our infrastructure for business process in our company.

I managed this week to deploy in about 2 hours a generic service for sending emails. this has always been a simple use case for SOA. 1 service on our network that has the single responsibility of sending emails.

done. for two years i've wanted to build it. only now with studying SOA, clean code and then the golden jewel of my professional life, NServiceBus. It's thing is amazing. Nothing else has come closer to demonstrating great code design. It's only now i've felt confident that committing to an architecture style of services is not going to dig a hole of maintainence and nightmare legacy. That's been my biggest fear of committing to technology. When i leave my employer i want positive things to be said about what i did in my time there. Not as the person that people curse when they go home at night because i've caused them pain.

in the midst of this leave request we've built two data views. leave requests that are mine and leave requests for my action. mine are ones that i started or were created for me, and forMyAction are ones that assigned to me || or are assigned to a role that i inherit.

we need to make these two views generic. view what is mine and what am i expected to be doing.

One place to go on the intranet to see these things. I don't want to give up and let the sharepoint system handle it. The coupling that we'd have to go through to get it in there is not something i EVER want to do. It goes against everything i've ever believed in.

The biggest problem for me is sharing hyperlinks between systems. if we have a generic system we need to keep the hyperlinks up to date.

therefore.... we have a service that is responsible for handling what the link for actions are.

I bought Rest In Practice a couple months back and in it they talk about HyperMedia formats. A JSON/XML representation of data, schema and behaviour. Therefore each time we send an object over the wire, we don't just send strings or dates or flags, we send over the applicable actions/commands that can be applied to the object via CommandNames and also hyperlinks to those actions.

Adding all the different types of behaviours into one large representation means A LOT of coupling and a lot of volatility. However as long as we keep the hyperlinks consistent in one system and design client systems to utilise them, all should be fine.

once these problems about responsibility are discussed, and attempts are made at to solve it, our interoperability abilities are increased 1000%.

Once we commit to making a system responsible for a part of the network then we mustn't duplicate that behaviour, anywhere, ever.