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 t