Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Message-oriented solution
    • no services actually know about one another
    • I as a service publish messages out into the ether, and those that are interested are subscribed to those messages and act based on them
    • Common pitfall is that message format tends to lead to hard dependencies
  • Feature-based / flags (lack of a better word)
    • re-uses / leverages RESTful HTTP approach (favored API re-use)
    • we want to make features turn on / off, and we do that by detecting the deployments intent - a Service is available if it was in the deployment descriptor (docker-compose)
    • we need to spike on how to:
      • read the docker-compose (docker-compose config --services) and create a feature flag based off services deployed
      • we need to publish (consul KV) those flag statuses and consume those in our services (constantly checking? No, config doesn't change.  We want on startup - onetime)
      • Requisition to Stock Mgmt is a good first step to implement (would spur the discussion about which "features" turn off)
        • all stock mgmt fields including reasons for losses and adjustments


Action Items

...