Page Comparison

...

• Ch 3. Bounded Contexts
  • Seams with Loose coupling and High cohesion
  • Beware of premature decomposition before domains and usages are solidified.
• Ch 4. Integration
  • Avoid database integration at all cost
  • DRY and code-reuse can couple microservices
  • Robustness principle: "Be conservative in what you do, be liberal in what you accept from others."
  • Sync vs Async
    
    • request/response vs event-based vs reactive (observe for results)
    • request/response can be sync or async - async by registering a callback
      
      • "orchestration" pattern leads to centralized authorities with anemic CRUD-based services
      • these systems are more brittle with a higher cost of change
      • technology choices
        • RPC
          • easy to use
          • watch out for: technology coupling, incorrectly treating remote calls as local calls, lock-step releases
        • REST over HTTP
          
          • more resilient to changes than RPC - sensible default choice
          • not suited for low latency and small message size (consider WebSockets) 
    • event-based - better decoupling; intelligence is distributed
      • "choreographed" pattern leads to implicit view of the business process (since no centralized workflow)
      • additional work to monitor/track - can create a monitoring system that matches the view of the business process - validates flowchart expectations
      • these systems are more loosely coupled, flexible, and amenable to change
      • technology choices
        • RabbitMQ
        • HTTP + ATOM
      • managing complexities
        • maximum retry limits
        • dead letter queue (for failed messages) - with UI to view and retry
        • good monitoring
        • correlation IDs to trace requests
  • Versioning
    • Postel's Law, a.k.a. Robustness principle: "Be conservative in what you do, be liberal in what you accept from others."
    • consumer-driven contracts to catch breaking changes early
    • semantic versioning - self-documented impact
    • expand and contract pattern when versioning breaking changes.
      • co-existing versions needed for blue-green deployments and canary releases
  • UI as the compositional layer
    • UI Fragment composition
      • server-side rendering of course-grained fragments work well when aligned with team ownership
      • problem: consistency of UX - mitigated with shared CSS/images/etc
      • problem: doesn't support native applications / thick clients
      • problem: doesn't work for cross-cutting features that don't fit into a widget/page
    • Backends for Frontends
      • aggregated backend layers, with dedicated backends serving UI/APIs for dedicated frontend experiences
      • danger: keep business logic within the underlying services.  Aggregated backends should contain only front-end specific behavior
    • Hybrid of both approaches above 
  • Third-party software
    • Build or Buy commercial-of-the-shelf?
      • "Build if it is unique to what you do, and can be considered a strategic asset; buy if your use of the tool isn't that special" - Build if core to your business
    • Problems with COTS
      • lack of control
      • customization - avoid complex customizations - rather, change your organization's functions
      • integration spaghetti - with different protocols, etc
    • On your own terms
      • Hide COTS CMS behind your own web frontend, putting the COTS within your own service facade
    • Use Strangler Application Pattern to capture and intercept calls to the old system