Finding your service boundaries - a practical guide (@adamralph, #ndc2018)

A lot of "technical issues" just fall away, once you restructure your service boundaries.

Create IDs before creating the object, so that you can communicate it downstream.

You can get rich business data from "leftover" data, such as incomplete orders (so that they can improve the purchase process, for example).

Consider services cutting through technical boundaries, aligning them with business needs. Consider naming your technical things 'systems'. Adam argues for taking components for multiple services, deploying them together as a technical system.

Find service boundaries by looking at transaction scopes - do we update things at the same time, then they belong together. Anti-requirements.

Don't look at entity terms, look at interactions. Look at singular fields and Use cases / interactions. If you're thinking "x has a .. ", you are probably having an entity mindset. 

Avoid naming things until much later, or name them things that doesn't make sense, such as "Mercury" instead of "Customer".

Service designers could be super useful here, since they are modelling "customer journeys".

Eric Evans wishes that the entity part of his book moved further to the end of the book, since entities lead us down the wrong path; they're bad, says @adamralph.

Since there are a lot of relationships between Policies and Claims, they are the wrong service boundaries. During a claim, a lot of information needs to be retrieved from the policy - what are we liable for. As you make more claims, the price on the policy goes up.

Business response: "Oh, but that's obvious" means that you've found a good/better boundary.
The modern department has become a mini kingdom. Anyone can do anything with our current technology, why organizational boundaries are a very unstable business boundary.

When you identify that you need to prioritize a class of messages, consider breaking out the logic to handle the prioritized messages into a new service.


There's a time to use SOA, adam ends with - in startups, for example, just get your business done. Refactor into SOA.


Comments

Popular posts from this blog

Auto Mapper and Record Types - will they blend?

Unit testing your Azure functions - part 2: Queues and Blobs

Testing WCF services with user credentials and binary endpoints