Opinion: When Designing Your SOA - Taste is Everything

Dan Creswell claims that "taste is everything" when it comes to putting together the pieces that make a good SOA. Dan  says that picking the technology stack for distributed services, how you layer the service "units", etc, are a matter of taste as well as consideration of a number of guidelines, as opposed to just taking a cookie cutter approach to SOA as some seem to claim is possible. Dan concludes providing some of his own guidelines for SOA.

According to Dan:

[...] we’d like to believe that architecture (and much of development) can be done with fixed rules, cookie cutter style, get your catalog of patterns and technology, apply them - job done. The ultimate embodiment of this behaviour is ... [thinking that] ... deploying an ESB [...] makes your system [an] SOA.

He says that even in good architectures data dependency is unavoidable, and suggests layering the code and data vertically to isolate service "units" higher up in the chain from having direct dependency on the data. This form of layering does have its own drawbacks because its bakes in assumptions of location agnosticity and synchronicity of invocation into the higher order service units. To avoid issues related to these assumptions, he suggests that "we deploy each unit in it’s own process accessed via some network endpoint that dependants use to interact with it". Such a deployment, he says, afford run-time performance benefits via techniques like 'sharding, horizontal scaling and load-balancing and maintainability in terms of testing and hot-patching these units. It also allows teams to work "independently of development efforts elsewhere, making for less contention in development".

He proposes the following set of guidelines on layering code and data and choosing distributed architectures and cautions that one still needed to think about consistency issues related with this design choice and "also take [into consideration] the fallacies of [distributed computing]":

1. Considering similarities in consistency, availability and partitioning (CAP) requirements
2. Data access localities
3. Data relationships
4. Jurisdictional requirements
5. Roles and responsibilities (at coarser level than OO)
6. Features (e.g. recommendations)
7. Business processes
8. Constituent elements of an overall business process

... and concludes by saying "most systems likely require a combination of these [guidelines] rather than one fixed approach, taste and gut instinct count for a lot." Be sure to check out the original post.