Posts Tagged ‘SOA’
[DevoxxBE2013] CQRS for Great Good
Oliver Wolf, principal consultant and executive board member at INNOQ, challenges conventional architectures with CQRS (Command-Query Responsibility Segregation). A SOA and Java expert, Oliver traces CQRS’s evolution from CQS, demonstrating incremental adoption—from read-write separation to event sourcing. His session, enriched with examples, equips developers to rethink data flows, optimizing for asymmetric workloads in banking and beyond.
CQRS decouples commands (writes) from queries (reads), enabling tailored models. Oliver illustrates phased implementation, culminating in event-sourced systems for auditability and scalability.
From CQS to CQRS: Foundational Concepts
Oliver recalls CQS—Bertrand Meyer’s principle segregating mutators from inspectors. CQRS extends this, allowing distinct read/write models. He demos a simple e-commerce app, splitting a unified model into command (order placement) and query (inventory views).
This separation, Oliver explains, resolves impedance mismatches, enhancing performance.
Incremental Adoption Strategies
Phased rollout minimizes risk: start with asymmetric databases, Oliver advises, using separate stores for reads/writes. He showcases materialized views, syncing via background jobs.
Advanced steps introduce event sourcing: commands emit events, replayed for state reconstruction, ensuring immutability.
Event Sourcing and Distribution
Event sourcing captures changes as immutable logs, Oliver illustrates, rebuilding state on demand. Distribution follows: client/server variants, with web frontends querying dedicated services.
In banking, Oliver notes, CQRS optimizes configurable systems, balancing risk with extensibility.
Guidelines for Application
Oliver urges starting small: identify read-heavy operations, segregate gradually. Avoid over-engineering; CQRS suits complex domains, not simple CRUD.
Community examples, he shares, validate phased approaches, with INNOQ projects exploring hybrid models.
Links:
[DevoxxBE2012] Architecture All the Way Down
Kirk Knoernschild, a software developer passionate about modular systems and author of “Java Application Architecture,” explored the pervasive nature of architecture in software. Kirk, drawing from his book on OSGi patterns, challenged traditional views, arguing architecture permeates all levels—from high-level designs to code.
He invoked the “turtles all the way down” anecdote to illustrate architecture’s recursive essence: decisions at every layer impact flexibility. Kirk critiqued ivory-tower approaches, advocating collaborative, iterative practices aligning business and technology.
Paradoxically, architecture aims for change resistance yet adaptability. Temporal dimensions—decisions’ longevity—affect modularity: stable elements form foundations, volatile ones remain flexible.
Kirk linked SOA’s service granularity to modularity, noting services as deployable units fostering reuse. He emphasized patterns ensuring evolvability without rigidity.
Demystifying Architectural Paradoxes
Kirk elaborated on architecture’s dual goals: stability against volatility. He used examples where over-design stifles agility, advocating minimal upfront planning with evolutionary refinement.
Temporal hierarchies classify decisions by change frequency: strategic (years), tactical (months), operational (days). This guides layering: stable cores support variable extensions.
Granularity and Modularity Principles
Discussing granularity, Kirk warned against extremes: monolithic systems hinder reuse; overly fine-grained increase complexity. Patterns like base and dependency injection promote loose coupling.
He showcased OSGi’s runtime modularity, enforcing boundaries via exports/imports, preventing spaghetti code.
Linking Design to Temporal Decisions
Kirk connected design principles—SOLID—to temporal aspects: single responsibility minimizes change impact; open-closed enables extension without modification.
He illustrated with code: classes as small modules, packages as mid-level, OSGi bundles as deployable.
SOA and Modular Synergies
In SOA, services mirror modules: autonomous, composable. Kirk advocated aligning service boundaries with business domains, using modularity patterns for internal structure.
He critiqued layered architectures fostering silos, preferring vertical slices for cohesion.
Practical Implementation and Tools
Kirk recommended modular frameworks like OSGi or Jigsaw, but stressed design paradigms over tools. Patterns catalog aids designing evolvable systems.
He concluded: multiple communication levels—classes to services—enhance understanding, urging focus on modularity for adaptive software.
Kirk’s insights reframed architecture as holistic, from code to enterprise, essential for enduring systems.