The 'easy parts' of architecture have known best practices. The hard parts are the decisions with no textbook right answer — how finely to split services, how to break apart a shared database, how to keep data consistent when it no longer lives in one place. These are trade-off analyses, not recipes.

Software Architecture: The Hard Parts frames the architect's real job as making these trade-offs explicit: identifying the forces that push a system apart and those that hold it together, and choosing deliberately rather than by fashion.

For service granularity, the book names two opposing sets of forces. Disintegrators are reasons to break a service into smaller pieces: service scope and function (single responsibility), code volatility (parts that change at different rates), scalability and throughput differences, fault tolerance (isolating failure), security needs, and differing data or access requirements. Integrators are reasons to keep or merge services: database transactions (needing consistency in one place), data dependencies, and workflow/choreography that would otherwise incur heavy communication. Right-sizing a service means balancing these opposing forces, not maximizing smallness.

For data decomposition, the book gives disintegrators (change control, connection management, scalability, fault tolerance, separation of concerns, independent deployability) and integrators (data relationships, database functions, and data consistency needs) for deciding whether to split a monolithic database into separate ones.

Once data is split, you face distributed data problems: how services access data they no longer own (data ownership, and patterns to read remote data), and distributed transactions, which cannot use ACID guarantees and instead rely on eventual consistency, sagas, and patterns to reason about consistency versus availability.

A monolith bundles Order Management and Fraud Detection in one service. Two disintegrator forces argue for splitting them: Fraud Detection changes weekly (code volatility) and needs to scale independently at peak (scalability differences). But an integrator force pushes back: an order and its fraud check are currently updated in a single database transaction (transactional integrity).

The architect weighs these explicitly. If the business can tolerate the fraud check being eventually consistent — resolved slightly after the order is placed — the disintegrators win and the split proceeds. The team then decomposes the shared database, assigning Fraud Detection its own data, and replaces the lost ACID transaction with a saga and eventual consistency, accepting a well-understood window of inconsistency in exchange for independent deployability and scaling.

This is the recurring shape of the hard parts: name the forces, decide which dominate for this context, and pay the resulting trade-off knowingly.

Service and data boundaries are where DDD's bounded contexts become physical deployables, and the distributed transactions here are managed with the sagas and compensating actions from Communication Patterns. The coupling created by data dependencies is measured by Architecture Metrics.

And because every split risks regressing coupling, latency, or contract compatibility, evolutionary fitness functions guard the decompositions the Hard Parts recommends — the topics form one continuous chain from strategy to runtime.