Skip to content

Instantly share code, notes, and snippets.

@gabrieljoelc

gabrieljoelc/journal.dev.udidahanqanda.md

Last active June 16, 2020 17:33
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save gabrieljoelc/dc5362bc61699e902907c985d30e4b24 to your computer and use it in GitHub Desktop.
Save gabrieljoelc/dc5362bc61699e902907c985d30e4b24 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
journal.dev.udidahanqanda.md

  • Data distribution vs. pub/sub

    • Data distribution is physical architecture
    • Pub/sub is more focused on logical architecture

  • Udi's "service" is a logical entity vs. component physical entity (a piece of code running in one or more hosts)

  • Preferred interaction

  • Avoid crossing network boundaries within service boundaries

  • Service - technical authority for a business capability

  • Data distribution from a database to a frontend is likely within the same logical service boundary

  • For pub/sub communicating between differing business capabilities usually doesn't care about low latency

  • For data distribution, you often care about low latency

  • Saga's are owned by one and only one business capability

  • Transactions must need to be within the same logical service boundary

  • Systems are physical and can contain multiple logical service boundary business components deployed to them

  • Pub/sub masquerading as request/response

  • Microservice/autonomous component might be necessary because of load patterns

  • Outstanding question:

How do you deal with security concerns that make it difficult to avoid adding more network calls? For example, if you would like use a third party notification component to persist but can’t because the only correlation value contains PHI. Do you treat the PHI concern a separate business capability?

GistID: dc5362bc61699e902907c985d30e4b24

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment