Posts Tagged ‘softwaredeveloper’
[NDCOslo2024] Designing for Change with Vertical Slice Architecture – Chris Sainty
In the ever-shifting sands of software demands, where agility trumps rigidity and evolution outpaces stasis, Chris Sainty, a distinguished software architect and Microsoft MVP, advocates for a paradigm that embraces flux: Vertical Slice Architecture (VSA). With a wealth of experience in .NET ecosystems, Chris dissects the frailties of conventional layered paradigms, illuminating how VSA fosters adaptability, accelerates onboarding, and scales with success. His exposition, laced with pragmatic examples, challenges developers to reimagine structures that prioritize features over foundations, ensuring applications remain responsive to the inexorable tide of transformation.
Chris commences by lauding the endurance of layered architectures—presentation atop business logic atop data—yet probes their perils in contemporary contexts. As customer whims whirl and scaling surges demand swift pivots, layers ossify into obstacles, encumbering change with cross-tier tangles. VSA, conversely, carves applications into self-contained verticals—end-to-end features encapsulating all concerns—streamlining modifications and magnifying modularity. This feature-centric ethos, Chris argues, aligns with modern mandates: rapid iterations, effortless extensions, and intuitive ingress for new contributors.
Deconstructing Layers: Pitfalls of Traditional Tiering
Layered designs, Chris elucidates, excel in abstraction but falter in flux. Modifications ripple across strata—tweaking data access mandates presentation perturbations—breeding brittle bonds. Scaling amplifies agony: monolithic services swell, onboarding overwhelms with navigational nightmares. Chris recounts teams ensnared in “god classes,” where logic leeches into controllers, defying single-responsibility tenets.
VSA liberates by slicing vertically: each feature owns its orchestration, from input validation to persistence, minimizing interdependencies. In ASP.NET Core, MediatR handlers embody this, encapsulating requests with validators, mappers, and repositories. Chris demonstrates: a “Create Order” vertical integrates all facets sans layer leaks, easing evolution as requirements refine.
Trade-offs temper triumph: VSA risks redundancy in shared utilities, yet Chris counters with judicious extraction—domain entities for rules, infrastructure abstractions for emails—preserving purity without proliferation. His verdict: layers for legacy, VSA for vitality.
Embracing Verticals: Accelerating Agility and Onboarding
VSA’s virtues shine in speed: altering a feature confines chaos to its silo, slashing cycle times. Chris illustrates with e-commerce: updating checkout logic spans one slice, not sprawling services. Onboarding accelerates—newcomers grasp endpoints holistically, sans layer labyrinths—fostering faster fluency.
Scaling surges seamlessly: verticals deploy independently, microservices materialize modularly. Chris cautions misconceptions: VSA isn’t anarchy—tests tether slices, conventions coerce cohesion. In .NET, minimal APIs map verticals directly, ditching controllers for clarity.
His horizon: VSA as mindset, marrying DDD’s domains with feature focus, empowering teams to thrive amid tumult.
Navigating Nuances: Sharing Savvy and Strategic Choices
Code sharing, a VSA specter, resolves via domains: encapsulate business invariants—aggregates, entities—reusable across verticals, insulating infrastructure. Chris debunks duplication dogmas: external concerns like databases or notifications warrant abstraction, not replication, ensuring efficiency without entanglement.
Strategic selection: VSA suits volatile domains; layers linger in stable spheres. Chris’s compass: assess change cadence—frequent flux favors verticals.
Forging Forward: Building for the Inevitable
Chris’s capstone: architectures architect for alteration. VSA, with its slice-centric simplicity, equips ensembles to navigate novelty, nurturing nimble, navigable codebases that celebrate change.
Links:
[NDCOslo2024] Domain-Driven Design in Practice: How to Draw Your Domain Boundaries IRL – Vilde Opsal
In the dynamic crucible of organizational transformation, where business and technology converge, Vilde Opsal, an architect at FINN.no, narrates a saga of redrawing domain boundaries amidst a Nordic merger. As FINN.no and Schibsted Nordic Marketplaces shifted from horizontal silos to vertical units, Vilde orchestrated a domain-driven design (DDD) odyssey, harmonizing legacy maps with new strategies. Her case study, vibrant with real-world trials, illuminates how to craft domain boundaries that evolve with stakeholders, blending art, agility, and audience empathy.
Vilde frames her talk as a TV show, casting herself as the architect alongside product leads, developers, and a “big boss.” FINN.no’s reorganization—merging four marketplaces into a Nordic entity—demanded a new domain map to support independent verticals. Her mission: align historical domains, new teams, and strategic shifts, ensuring boundaries serve both immediate needs and long-term visions.
Crafting the Canvas: Principles of Domain-Driven Design
DDD, Vilde asserts, is an art, not a science. She begins with core tenets: domains as cohesive problem spaces, bounded contexts as clear partitions. At FINN.no, legacy boundaries—tied to functional areas like payments or listings—clashed with vertical ambitions. Her approach: engage stakeholders collaboratively, mapping domains via workshops that blend business goals with technical realities.
Vilde’s toolkit includes event storming, visualizing user journeys to delineate domains. For instance, real estate verticals prioritized distinct user journeys, while cars focused on transactional flows. This divergence necessitated tailored boundaries, ensuring each vertical’s autonomy while maintaining shared services like authentication.
Adapting to Audiences: Evolving Boundaries Over Time
Boundaries evolve, Vilde notes, as teams and goals shift. Early in the merger, real estate teams preserved legacy setups, minimizing disruption, while car verticals embraced user-centric journeys. She experimented with visualizations—temperature gauges, tables—to communicate progress, finding simplicity trumped flair. A table, mapping current versus aspirational states, resonated most, aligning diverse stakeholders.
Her insight: meet audiences where they are. Developers craved technical granularity; executives sought strategic clarity. By tailoring visualizations—diagrams for tech, narratives for business—Vilde bridged divides, ensuring domain maps clicked and stuck.
Balancing Pragmatism and Vision: Iterative Refinement
Pragmatism guided FINN.no’s journey. One vertical, pressed for time, made local decisions, deferring holistic reviews. Another, post-transformation, leaned on jobs-to-be-done, aligning domains to user needs. Vilde’s lesson: flexibility fosters progress. Iterative refinements, validated through experiments, ensured boundaries adapted to new stakeholders, like Nordic partners.
Her capstone: DDD thrives on dialogue. By fostering continuous feedback—workshops, retrospectives—teams co-create boundaries, balancing agility with coherence.
Embracing the Art: Making Domains Click
Vilde’s finale underscores DDD’s artistry: no universal blueprint exists. Success lies in experimentation, stakeholder alignment, and persistent iteration. Her challenge: craft domains that resonate, guiding teams from chaos to clarity with empathy and precision.
Links:
[NDCOslo2024] Reusable Ideas About the Reuse of Software – Audun Fauchald Strand & Trond Arve Wasskog
In the sprawling digital expanse of Norway’s welfare agency, NAV, where 143 million lines of code burgeon, Audun Fauchald Strand and Trond Arve Wasskog, principal engineers, confront the Sisyphean challenge of maintenance. Their discourse, a clarion call for strategic reuse, dissects NAV’s labyrinthine codebase, advocating for shared components to curb redundancy. With a nod to domain-driven design and Conway’s Law, Audun and Trond weave a narrative of organizational alignment, technical finesse, and cultural recalibration, urging a shift from ad-hoc replication to deliberate commonality.
NAV, serving Norway’s social safety net, grapples with legacy sprawl. Audun and Trond, seasoned navigators of this terrain, challenge the mantra “reuse should be discovered, not designed.” Their thesis: intentional reuse, underpinned by product thinking, demands ownership, incentives, and architecture harmonized with organizational contours. From open-source libraries to shared services, they map a spectrum of reuse, balancing technical feasibility with social dynamics.
Redefining Reuse: From Code to Culture
Reuse begins with understanding context. Audun outlines NAV’s scale: thousands of developers, hundreds of teams, and a codebase ballooning through modernization. Copy-pasting code—tempting for speed—breeds technical debt. Instead, they champion shared libraries and services, like payment gateways or journaling systems, already reused across NAV’s ecosystem. Open-source, they note, exemplifies external success; internally, however, reuse falters without clear ownership.
Trond delves into Conway’s Law: systems mirror organizational structures. NAV’s fragmented teams spawn siloed solutions unless guided by unified governance. Their solution: designate component owners, aligning incentives to prioritize maintenance over novelty. A payment service, reused across domains, exemplifies success, reducing duplication while enhancing reliability.
Technical Tactics and Organizational Orchestration
Technically, reuse demands robust infrastructure. Audun advocates platforms—centralized APIs, standardized pipelines—to streamline integration. Shared libraries, versioned meticulously, prevent divergence, while microservices enable modular reuse. Yet, technical prowess alone suffices not; social engineering is paramount. Trond emphasizes cross-team collaboration, ensuring components like letter-sending services are maintained by dedicated squads, not orphaned.
Their lesson: reuse is a socio-technical dance. Without organizational buy-in—financing, accountability, clear roles—components decay. NAV’s pivot to product-oriented teams, guided by domain-driven design, fosters reusable assets, aligning technical solutions with business imperatives.
Navigating Pitfalls: Ownership and Maintenance
The core challenge lies in the “blue box”—NAV’s monolithic systems. Audun and Trond dissect failures: reused components falter when unowned, leading to outages or obsolescence. Their antidote: explicit ownership models, where teams steward components, supported by funding and metrics. They cite successes—journaling services, payment APIs—where ownership ensures longevity.
Their vision: an internal open-source ethos, where teams contribute to and consume shared assets, mirrored by external triumphs like Kubernetes. By realigning incentives, NAV aims to transform reuse from serendipity to strategy, reducing code bloat while accelerating delivery.
Fostering a Reuse-First Mindset
Audun and Trond conclude with a cultural clarion: reuse thrives on intentionality. Teams must evaluate trade-offs—forking versus libraries, services versus platforms—within their context. Their call to action: join NAV’s mission, where reuse reshapes welfare delivery, blending technical rigor with societal impact.
Links:
[NDCOslo2024] Running .NET on the NES – Jonathan Peppers
In a whimsical fusion of nostalgia and innovation, Jonathan Peppers, a principal software engineer at Microsoft, embarks on an audacious quest: running .NET on the Nintendo Entertainment System (NES), a 1985 gaming relic powered by a 6502 microprocessor. With a career steeped in .NET for Android and .NET MAUI, Jonathan’s side project is a playful yet profound exploration of cross-platform ingenuity, blending reverse engineering, opcode alchemy, and MSIL wizardry. His journey, shared with infectious enthusiasm, unveils the intricacies of adapting modern frameworks to vintage hardware, offering lessons in creativity and constraint.
Jonathan opens with a nod to the NES’s cultural cachet—a living room arcade for a generation. Its modest specs—less than 2 MHz, 52 colors, and minuscule cartridges—contrast starkly with today’s computational behemoths. Yet, this disparity fuels his ambition: to compile C# into 6502 assembly, enabling .NET to animate pixels on a 256×240 canvas. Through meticulous reverse engineering and bespoke compilers, Jonathan bridges eras, inviting developers to ponder the portability of modern tools.
Decoding the NES: Reverse Engineering and Opcode Orchestration
The NES’s heart, the 6502 microprocessor, speaks a language of opcodes—terse instructions dictating arithmetic and flow. Jonathan recounts his reverse-engineering odyssey, dissecting ROMs to map their logic. His approach: transform C#’s intermediate language (MSIL) into 6502 opcodes, navigating the absence of high-level constructs like methods or garbage collection. By crafting a custom compiler, he translates simple C# programs—think console outputs—into assembly, leveraging the NES’s 2KB RAM and 8-bit constraints.
Challenges abound: switch statements falter, branching logic stumbles, and closures remain elusive. Yet, Jonathan’s demos—a flickering sprite, a basic loop—prove viability. His toolkit, open-sourced on GitHub, invites contributions, with a human-crafted logo replacing an AI-generated predecessor. This endeavor, while not production-ready, showcases the power of constraints to spark innovation, echoing the NES’s own era of elegant simplicity.
Bridging Eras: Lessons in Cross-Platform Creativity
Jonathan’s experiment transcends mere novelty, illuminating cross-platform principles. The NES, with its rigid architecture, mirrors edge devices where resources are scarce. His compiler, mapping .NET’s abstractions to 6502’s austerity, mirrors modern efforts in WebAssembly or IoT. Structs, feasible sans garbage collection, hint at future expansions, while his call for pull requests fosters a collaborative ethos.
His reflection: constraints breed clarity. By stripping .NET to its essence, Jonathan uncovers universal truths about code portability, urging developers to question assumptions and embrace unconventional platforms. His vision—a C# Mario clone—remains aspirational, yet the journey underscores that even vintage hardware can host modern marvels with enough ingenuity.