./resources/architecture-the-hard-parts-semantic-vs-implementa.resources/unknown_filename.png

if the semantics of your problem change
then everything else needs to change

prevent implementation coupling, that makes your architecture brittle


contracts: strict vs loose ./resources/architecture-the-hard-parts-semantic-vs-implementa.resources/unknown_filename.1.png method calls “schema” serialized objects RPC remote procedure call graphql (aggregation framework, not a invocation framework) value-driven contracts json KVP key value pairs

example: brittleness ./resources/architecture-the-hard-parts-semantic-vs-implementa.resources/unknown_filename.2.png not brittle: changing the type of country, does not break the contract for wishlist

./resources/architecture-the-hard-parts-semantic-vs-implementa.resources/unknown_filename.4.png support all versions forever? => deprecation strategy

./resources/architecture-the-hard-parts-semantic-vs-implementa.resources/unknown_filename.3.png

./resources/architecture-the-hard-parts-semantic-vs-implementa.resources/unknown_filename.5.png https://martinfowler.com/articles/consumerDrivenContracts.html

pact

  • sync: rest
  • async: events (kafka / rabbitmq)

./resources/architecture-the-hard-parts-semantic-vs-implementa.resources/unknown_filename.6.png

looser?

  • deployability (delay in updating versions in app store, old versions on customer phones)
  • integration points (app stores)