...
- 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)
- RPC
- 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
- UI Fragment composition
- 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
- Build or Buy commercial-of-the-shelf?