Tech Books Summary

_Tech Books Summary_.md

Somewhat curated sumamries of technical materials. Take it with a grain of salt

Clean Architecture.md

Clean Architecture (2022 H2)

Good architecture:

• good architecture = allow changes w/ flexibility + delay decision

Business rules:

• Entities: pure; small sets of critical business rules. Should be most independent & reusable. Can be an object with methods or data structures & functions
• Use case: not as pure; is an object. contains data elements & operations.
• Entities are lower level than (don’t depend on) use cases since use cases are closer to inputs/outputs.
• Entities & use cases are 2 layers
• Returned data structure should not reference entities since they might change for diff. reasons

Screaming architecture:

• System should describe what it does not what framework it uses

The clean architecture:

• Use case layer contains application-layer biz rules. Changes at this layer shouldn’t affect entity layer
• Changes to workflow requires updating use case layer
• Adapter layer: convert data from/to use cases & entities to/from external (web/DB). Example: Views and controllers in MVC; other data from/to internal/external form
• Dependency rule: Dependency should point inward (lower level layers)
• If need to call from inner to outer layer, inner should call an interface implemented by outer layer. Both inner & outer will depend on (point to) interface
• Data crossing boundaries should be simple or just function args (no entities)
• Interface adapters: covert data from format of inner layer to the format of external layer

Presenters and humble objects:

• Presenter accepts data from application and applies formatting. Presenters are testable
• View (humble object) receive view model from presenters w/o processing. Views display the data
• Humble object patterns separates testable (non-humble) and non-testable (humble) parts
• Objects are not data structure. Objects is a set of operations (pubic methods). DS has no behaviors
• Humble object pattern is likely found in every architectural boundary

Monolith to Microservices.md

Monolith to Microservices (2023 H1)

• 1 Just Enough Microservices
• 2 Planning a Migration

---

1 Just Enough Microservices

...

2 Planning a Migration

• MS is not the goal, goal might be e.g. faster delivery, team automany, break off from monolith release cycle. Need ROI calculation, ned to align with what business tries to achieve
• Consider microservice alternatives, or try things in parallel. Alternative ideas:
  • Modular monolith
  • Vertical scaling (more powerful machine)
  • Horizontal scaling (more machines)
  • Scale up development team
  • New technology
  • Use sliders to analyze competing priorities
• Faster delivery: should run path-to-production analysis to find the biggest blocker
• MS: Benefits
  • More robust architecture (ability to react to expected variations) because of decomposed functionality
  • Great options for scale-up after initial success
• MS: When's MS a bad idea
  • Unclear domain/decompose prematurely
  • Startup/greenfield project
  • Customer-installed software
  • Lack of good reason
• Incremental migration:
  • Start somewhat small
  • The impact of decomposition will be relfected in production env, not during development
  • Easier places to experiment - start with whiteboarding
• Where to start migration/decomposiition
  1. Develop domain model with just enough info (e.g. use event-storming)
  2. identify bounded context
  3. BC is good starting points for defining MS boundaries
  4. map out BC dependencies to determind which is easier to extract (Fig 2.6)
  5. caveat: domain model represents logical view, not how code is organized
  6. Use trade-off diagram (benefit of decomposition vs ease of decomposition) to prioritize decomposiition (Fig 2.8)
• Reorganizing teams
  • DevOps (independent, autonumous teams)
  • Changing/improving developer skills
• How to know if transition is working
  • Define measures to track
  • Regular checkpoints (review quantitative + qualitative measures)
  • quantitative measures e.g. number of deployments, failure rates, cycle time
  • qualitative measures e.g. team's feelings
  • Avoid sunk cost fallacy
  • Key: take small steps, be open to new approaches
• Misc.
  • "Reuse is not a direct outcome people want. Reuse is something people hope will lead to other benefits"
  • Irreversible vs reversible decisions

System Design Fundamentals.md

System Design Fundamentals - Juval Lowy (2023 H1)

---

1 What not to do

• Avoid functional decomposition, or domain decomposition
• Avoid bloating clients/thin service

2 What to do

• Decompose based on volatility
• Each areas of change is encapsulated (in a vault) - each represents an area of volatility
• No block if no volatility

3 Using layers

• Ask:
  • are volatilities in software system?
  • any interaction between areas of volatility?
• layers imply top-down. Each layer is also an encapsulation. Within a layer are services (entities)
• layers (top to bottom):
  • client layer (user/another system/techs) - volatility in client technology. Try to equalize all clients -- single point of entry to system
  • business layer - volatility in changes of system behavior. Good requirement is always behavioral (leave less room for interpretation) not functional i.e. use case.