What is *Lean Architecture* by James O. Coplien about?

*Lean Architecture* explores how to apply lean principles to software development, balancing agility with structural integrity. It introduces the DCI (Data, Context, Interaction) paradigm to guide architecture while minimizing waste, emphasizing stakeholder alignment, and separating system domain models from functionality. The book bridges Agile practices with sustainable architectural design for scalable, adaptable systems.

Who should read *Lean Architecture* by James O. Coplien?

Software architects, Agile developers, and project managers tackling complex systems will find this book invaluable. It’s also relevant for Lean practitioners seeking to integrate architectural rigor into iterative workflows and teams aiming to reduce rework through clearer design guidelines.

Is *Lean Architecture* by James O. Coplien worth reading?

Yes, particularly for those navigating large-scale Agile projects. The book offers actionable strategies to harmonize rapid development with long-term system stability, providing frameworks like DCI and practical insights into documentation, stakeholder collaboration, and iterative design.

What are the key principles of Lean Architecture?

- **Balancing agility and structure**: Enough architecture to guide development without over-engineering. - **Stakeholder involvement**: Capturing diverse perspectives early to reduce misunderstandings. - **Domain-function separation**: Isolating what the system *is* from what it *does* for flexibility. - **Minimal documentation**: Prioritizing actionable artifacts like code-driven architectures.

How does *Lean Architecture* integrate with Agile methodologies?

The book positions architecture within Scrum and XP by advocating for lightweight upfront design, iterative refinement, and tools like use cases. It emphasizes code-as-documentation and the DCI paradigm to align Agile sprints with systemic coherence.

Does *Lean Architecture* recommend up-front design?

Yes, but in a lean manner: architects define core domain models and interfaces early, then refine them iteratively. This approach avoids excessive documentation while ensuring technical and business alignment.

What is the DCI paradigm in *Lean Architecture*?

DCI (Data, Context, Interaction) separates system data (domain models) from contextual behavior (use cases), enabling clearer object-oriented design. It addresses limitations in traditional OOP by modeling user mental models directly in code.

How does *Lean Architecture* handle documentation?

It prioritizes “just enough” documentation, such as whiteboard sketches or CRC cards, over exhaustive specs. The focus is on artifacts that directly guide development, like compilable architecture code.

애자일 소프트웨어 개발을 위한 린 아키텍처

제임스 O. 코플리엔 & 게르트루드 비외른비그

3.23(178 Reviews)

애자일 소프트웨어 개발을 위한 린 아키텍처 개요

애자일의 유연성과 아키텍처의 선견지명을 결합하여 소프트웨어 개발에 혁신을 일으키세요. 콘웨이의 법칙(Conway's Law)이 팀의 생산성을 변화시킬 수 있을까요? 업계의 판도를 바꾸는 이 가이드는 단순히 "리팩터링만으로 더 나은 아키텍처를 만들 수 있다"는 통념을 깨뜨립니다. 이는 현재 거대 IT 기업들이 소프트웨어를 구축하는 방식을 재편하고 있는 놀라운 통찰입니다.

전달 방식을 선택하세요

한 권의 책, 다양한 듣기 방식.

애자일 소프트웨어 개발을 위한 린 아키텍처의 같은 아이디어를 담았습니다. 나에게 맞는 목소리, 깊이, 속도를 고르고 언제든 바꿔 보세요.

1장

Reimagining Software Architecture for the Agile Age

When James O. Coplien and Gertrud Bjrnvig published "Lean Architecture for Agile Software Development" in 2010, it arrived at a pivotal moment in software development history. The industry was still reconciling the revolutionary Agile Manifesto with decades of established architectural practices. Their book became a quiet influencer among thoughtful developers seeking to balance agility with solid design principles. Unlike many technical books that fade quickly, it has maintained relevance over a decade later, with software architects at companies like Spotify and Netflix citing it as foundational to their thinking about sustainable systems. The book's central premise-that architecture and agility aren't enemies but essential partners-continues to challenge the false dichotomy that has divided development teams for years.

2장

Architecture and Agility: Partners, Not Adversaries

For too long, the software industry has operated under a misconception that architecture and agility are fundamentally opposed. On one side stand the "big up-front design" advocates who believe every system detail must be meticulously planned before coding begins. On the other side are those who believe architecture emerges organically through continuous refactoring, with minimal advance planning. Coplien and Bjrnvig reject this false dichotomy. They argue that architecture and agility are complementary forces that, when properly balanced, create systems that are both responsive to change and structurally sound. The authors draw inspiration from Coplien's grandfather Harry Grinnell, a postal worker and craftsman who embodied the balance between careful planning and practical execution. Harry built structures that were both well-designed and adaptable, focusing on solid foundations while remaining flexible about details that might change. This balance is at the heart of Lean Architecture. The approach emphasizes establishing just enough architectural foundation-primarily focused on form rather than implementation-to provide structure without constraining agility. Like a well-designed house foundation that supports various interior configurations, good software architecture provides a stable platform that enables, rather than restricts, change. The authors distinguish between what a system is (its relatively stable form) and what it does (its more frequently changing functionality). Architecture should focus primarily on capturing the stable aspects of system form, creating a framework within which features can evolve rapidly. This distinction helps teams avoid both the paralysis of excessive planning and the chaos of insufficient structure.

들리는 모든 단어를 눈으로 확인하세요

애자일 소프트웨어 개발을 위한 린 아키텍처의 각 단어가 오디오에 맞춰 실시간으로 강조되어 편하게 따라 읽을 수 있습니다.

3장

The Lean Secret: Everybody, All Together, Early On

Perhaps the most powerful insight in the book is what the authors call "The Lean Secret": bringing everybody together, from early on. This simple principle challenges the sequential handoffs common in traditional development, where architects design, developers implement, and testers verify in isolation from each other. The authors argue that the waste in software development isn't primarily from writing unnecessary code, but from the wait states and miscommunications that occur when teams work in isolation. When architects, developers, testers, and business stakeholders collaborate from the beginning, they create shared understanding that dramatically reduces rework and accelerates delivery. This approach embodies the Lean principle of eliminating waste by shortening feedback loops. When a cross-functional team works together on architecture, questions that might take weeks to resolve through formal channels can be answered in minutes. What appears to be "just talking" to casual observers is actually a crucial investment that prevents costly misunderstandings later. The authors share Diana Velasco's revealing example: during a site visit to observe users in their natural environment, she discovered sticky notes around computer screens and "crib sheet" notebooks that were essential to users' workflow but had never been mentioned in requirements discussions. These discoveries came from architects spending time in the end user environment-embodying the Japanese concept of genchi genbutsu ("go look and see"). Such insights are nearly impossible to capture through formal requirements processes alone.

4장

Problem Definition: The Compass for Development

Another key insight is the importance of clear problem definition in software development. The authors make a crucial distinction between problems (the measurable gap between current and desired states) and solutions (specific approaches to closing that gap). Too often, developers fall into the trap of solution-thinking, citing technical approaches like "becoming more object-oriented" or "implementing microservices" when asked what problem they're solving. This confusion can lead teams down costly paths of implementing solutions that don't address the core issues. A good problem definition serves as a compass for development, providing clear direction without over-constraining potential solutions. It should meet several specific criteria: be written down to ensure shared understanding, explicitly express the difference between current and desired states, include measurable outcomes that can be verified at a specific time, remain concise (typically one or two sentences), and maintain internal consistency across all aspects of the definition. For example, instead of stating "The system is too slow," a better problem definition might be "Database queries currently take 10 seconds on average, but need to complete within 2 seconds to meet customer satisfaction targets by Q3." The process of discussing and defining the problem is often more valuable than the final definition itself. It forces teams to confront their assumptions, align their understanding of what they're trying to achieve, and surface hidden constraints or requirements. The authors recommend several techniques for problem refinement, including the "Five Whys" method, which helps transform weak problem statements into focused, actionable definitions by driving to root causes. For instance, starting with "We need a new user interface" might lead through several "why" questions to reveal the real problem: "Our current interface requires users to navigate through seven screens to complete common tasks, resulting in 30% of users abandoning the process." In true Agile organizations, problem ownership is expanded beyond traditional boundaries so that definitions open possibilities rather than allocate blame. This manifests differently across roles in Scrum: the Product Owner owns the ROI vision problem ("How do we increase market share by 15%?"), the Team owns the implementation problem ("How do we deliver these features while maintaining system stability?"), and the ScrumMaster owns process improvement problems ("How do we reduce our sprint planning overhead by 50%?"). This distributed ownership ensures that problems are addressed at the appropriate level while maintaining alignment with overall objectives. Clear problem definitions also facilitate better decision-making throughout the development process. Teams can use them as criteria for evaluating potential solutions, prioritizing work, and determining when they've successfully addressed the issue. Regular review of problem definitions helps teams stay focused on delivering value rather than getting caught up in technical details or solution-specific debates.

애자일 소프트웨어 개발을 위한 린 아키텍처에서 더 많은 것을 얻으세요

매일 새로운 인사이트를 10만 개 이상의 레슨에서 만나보세요
단어가 강조되어 오디오와 실시간으로 동기화됩니다
내 라이브러리를 저장하고 모든 기기에서 이용하세요

5장

Domain Models: The Architectural Foundation

The book places significant emphasis on domain models as the foundation for good architecture. Domain models represent the relatively stable business concepts that underlie a system-concepts like "account," "customer," or "transaction" in banking systems. These models aren't merely technical constructs but representations of the mental models that end users carry in their heads. When the architecture accurately reflects these mental models, users find the system intuitive and developers can more easily accommodate change. The authors argue that capturing these models well is one of the most important architectural activities. Domain knowledge represents the timeless compression of stakeholder mental models into a coherent structure. While individual features may come and go, the underlying domain concepts tend to remain stable over much longer periods. For example, while banking features have evolved dramatically over decades, core concepts like accounts, transactions, and balances have remained relatively constant. The book recommends expressing domain models through abstract base classes that define interfaces without implementation details. These classes serve as poka-yoke (fool-proofing tools) that preserve system form while contributing nothing to the product footprint. This approach keeps domain classes deliberately "dumb," focusing on what the system is rather than what it does.

6장

From User Stories to Use Cases: Capturing System Behavior

While domain models capture what the system is, use cases capture what the system does. The authors acknowledge the value of user stories as a starting point but argue they often lack the context and completeness needed for effective development. Consider the user story: "As an Account Holder, I want to transfer money between accounts so none become overdrawn." This raises many questions: Who is the Account Holder? Will they use online banking, visit a branch, or call? Can transfers occur between different banks? What happens with negative balances? Can transfers be scheduled or recurring? Use cases provide a framework for addressing these questions systematically. They include not just the "happy path" (what happens when everything goes well) but also deviations and exceptions. A well-structured use case includes numbered steps showing the back-and-forth between actor intentions and system responsibilities, with actors and systems explicitly named at each step. The authors emphasize that use cases should be developed collaboratively, with business stakeholders, developers, and testers all participating. This collaboration ensures that the resulting scenarios capture both business needs and technical considerations. The terminology used in scenarios becomes direct input to the architecture, so terms must be carefully chosen and consistently applied. Use cases provide naturally sliced units for release planning. The sunny day scenario typically becomes highest priority, with deviations implemented according to business value. Since deviations (not sunny day scenarios) constitute the bulk of complexity, they provide flexible units for priority adjustments.

들리는 모든 단어를 눈으로 확인하세요

애자일 소프트웨어 개발을 위한 린 아키텍처의 각 단어가 오디오에 맞춰 실시간으로 강조되어 편하게 따라 읽을 수 있습니다.

7장

The DCI Architecture: Bridging Mental Models and Code

Perhaps the most innovative aspect of the book is its introduction of the Data, Context, and Interaction (DCI) architecture. DCI addresses a fundamental limitation of traditional object-oriented design: the disconnect between how users think about system behavior and how that behavior is implemented in code. In traditional OO, behavior is fragmented across domain objects, making it difficult to understand or modify complete use cases. For example, a money transfer operation might have pieces scattered across Account, Transaction, and Ledger classes. This fragmentation makes it hard for developers to reason about the complete operation. DCI separates what the system is (domain objects) from what it does (use cases) and connects them through a Context object. Domain objects remain focused on representing business entities, while use case logic is captured in "object roles" that can be dynamically assigned to domain objects when needed. For example, in a money transfer scenario, a SavingsAccount might temporarily play the role of "TransferMoneySource" with specific responsibilities like checking balances and withdrawing funds. Another account might simultaneously play the role of "TransferMoneySink" with responsibilities for receiving and depositing funds. The Context object coordinates these roles, binding them to appropriate domain objects for the duration of the use case. This approach has several advantages: 1. It keeps domain objects focused on their core responsibilities 2. It localizes use case logic in cohesive modules rather than fragmenting it 3. It directly reflects the end user's mental model of the system in code 4. It makes changes to use cases easier to implement and understand The authors provide detailed implementations of DCI in multiple languages including Ruby, C++, Scala, and Python, demonstrating how the concept can be adapted to different programming environments.

8장

MVC-U: Connecting Users to Systems

The book positions DCI within the broader context of the Model-View-Controller-User (MVC-U) architecture, introducing a crucial human-centric perspective to the traditional MVC pattern. The addition of "U" emphasizes the often-overlooked human element in technical architectures, acknowledging that software exists primarily to serve human needs and mental models. MVC-U establishes clear responsibility boundaries while maintaining cohesive interaction: • Models serve as the authoritative source of data, maintaining business rules and state. They update data based on commands and notify views of changes through observer patterns. Models remain completely unaware of their visual representation. • Views transform raw data into visual or tactical representations that users can comprehend and manipulate. They handle direct user input and maintain their specific presentation logic, whether displaying data as charts, tables, or interactive forms. Multiple views can represent the same data differently for various use cases. • Controllers orchestrate the overall system behavior, creating and managing view lifecycles, handling navigation and selection across different views, and translating user intentions into model commands. They serve as mediators that maintain system-wide consistency and manage complex view relationships. • Users interact with the system through their pre-existing mental models, which are shaped by past experiences, cultural context, and natural intuitions about how things should work. This framework helps programmers create compelling digital illusions that align with users' mental models, effectively bridging the gap between human cognitive patterns and computer data structures. In complex systems where multiple views present different aspects of the same underlying data (like showing both a spreadsheet and graph of financial data), the Controller takes on the crucial role of coordinating these views and maintaining consistency across representations. The authors emphasize that truly successful programs achieve a state of "transparency" where the computer's presence fades away, allowing users to feel directly connected to their work. Every program, at its core, creates an illusion - whether it's managing inventory, editing documents, or analyzing data. When retrieving an item from a digital warehouse system, users aren't physically handling goods, but the software creates such a convincing metaphor that the end result feels as natural as physical interaction. The most effective software illusions map directly to mental models users already possess, leveraging familiar concepts and patterns. For example, desktop interfaces succeed by mapping to real-world office metaphors, while touch interfaces work by matching natural gesture patterns. This alignment between system design and user expectations reduces cognitive load and increases both efficiency and user satisfaction.

애자일 소프트웨어 개발을 위한 린 아키텍처에서 더 많은 것을 얻으세요

매일 새로운 인사이트를 10만 개 이상의 레슨에서 만나보세요
단어가 강조되어 오디오와 실시간으로 동기화됩니다
내 라이브러리를 저장하고 모든 기기에서 이용하세요

9장

Documentation in the Lean and Agile World

The book takes a nuanced approach to documentation, avoiding both the excessive documentation of traditional methods and the documentation aversion sometimes found in Agile circles. Documentation serves two crucial functions: communicating perspectives and decisions, and remembering them. The Agile mindset often misses this distinction and dismisses all documentation. While the Manifesto contrasts documentation waste with working code, it doesn't reject documentation entirely. The authors recommend focusing on documentation that "packs the punch" rather than being comprehensive. The most valuable documentation describes relationships not visible in code. They suggest thinking of architectural documentation as an "as-built" rather than a forward engineering document, since code should be the primary forward engineering artifact. One specific document they recommend is the Domain Dictionary-a concise, incrementally developed glossary that defines key terms like "customer" or "account." This document establishes common vocabulary that prevents misunderstandings and builds shared vision. It should be stakeholder-reviewed and developed during analysis. The authors also emphasize the importance of capturing the "why" behind design decisions. While code shows what and how, only documentation explains why. Documentation provides broader context that's difficult to see in local code chunks, serving as a roadmap for different stakeholders.

10장

Balancing BUFD and YAGNI

The question of "how much architecture" remains one of the most polarizing topics in software engineering. Critics of segregated up-front architecture efforts use the disparaging term BUFD (big up-front design), viewing it as wasteful overplanning that delays actual development. On the opposite end, advocates of minimal architecture promote YAGNI (you ain't gonna need it), arguing for building only what's immediately necessary. The authors argue that neither extreme position serves projects well in practice. The optimal approach seeks a careful balance: implementing just enough architecture to enable efficient development and minimize expensive rework, while avoiding the creation of unused artifacts that add complexity without value. This balance point isn't universal but varies significantly by organization based on factors like code mass, stability requirements, team size, and regulatory constraints. BUFD typically fails for several key reasons: requirements emerge and evolve during development rather than being fully knowable upfront; market feedback on speculative functionality comes too late; and extensive early design can create rigid structures that resist necessary change. However, YAGNI arguments can be dangerously naive - analogous to waiting to build a house's basement until you need a recreation room. Architecture provides both functional structure and foundational form that shapes the entire system's evolution. The key lies in finding the minimum point in the cost curve where architecture investment yields optimal returns. This means having enough architecture to: • Enable parallel development across teams • Maintain system consistency • Support critical quality attributes • Allow for future growth • Minimize technical debt Architecture can be considered "done" when it meets several critical criteria: • Contributes meaningfully to solving long-term technical and business problems • Can be effectively tested and validated • Has identified readers for all documentation produced • Demonstrates capacity for evolution as requirements change • Supports different market segments and deployment scenarios • Uses consistent vocabulary and plain language throughout • Is well understood by the entire development team • Balances immediate needs with strategic technical goals Organizations should regularly reassess their architectural decisions, treating architecture as a living artifact that evolves with the system rather than a one-time deliverable. This approach helps maintain the delicate balance between over-engineering and insufficient foundation, allowing teams to adapt their architectural strategy as project needs evolve.

들리는 모든 단어를 눈으로 확인하세요

애자일 소프트웨어 개발을 위한 린 아키텍처의 각 단어가 오디오에 맞춰 실시간으로 강조되어 편하게 따라 읽을 수 있습니다.

11장

Conclusion: The Human Element in Software Architecture

Throughout the book, the authors emphasize that software development is fundamentally a human activity. The best architectures arise not from rigid processes or sophisticated tools, but from effective collaboration between skilled individuals with diverse perspectives. This human-centric approach acknowledges that successful software systems emerge from the collective intelligence, creativity, and experience of teams working together. Like Grandpa Harry building a cozy house without formal methods, or a tightrope walker performing on instinct, beauty in software comes from practice and experience rather than notation or scientific grounding. These processes depend on feedback, which requires humility toward future uncertainties. Just as a craftsman develops intuition through years of hands-on work, software architects must cultivate their instincts through practical experience and learning from both successes and failures. The comparison to traditional architecture becomes particularly relevant when the book references Christopher Alexander, an architect of the built world, who speaks of great architecture arising from millions of selfless individual acts. Alexander emphasizes that places must be designed by all people, not just professionals-a sentiment that aligns perfectly with the book's core message about collaborative architecture. This democratization of design suggests that the best solutions often emerge when we embrace diverse viewpoints and encourage participation from all stakeholders, including developers, users, and business experts. Though computing is young-with domain analysis dating only to 1980 and DCI to 2009-the future belongs to those who can balance structure with flexibility, planning with adaptation, and individual expertise with collective wisdom. This balance is crucial in an industry where change is constant and requirements evolve rapidly. Successful architects must learn to embrace uncertainty while maintaining enough structure to guide development effectively. The principles of Lean and Agile methodologies provide a framework for this balance, emphasizing iterative development, continuous feedback, and adaptive planning. These approaches acknowledge that software architecture is not about creating perfect, unchangeable designs, but rather about establishing flexible foundations that can evolve with changing needs. The most successful architects are those who can combine technical excellence with emotional intelligence, understanding both the logical and human aspects of software development. The conclusion reinforces that great software architecture is as much about people as it is about technology. It requires creating environments where creativity can flourish, where communication flows freely, and where teams feel empowered to make decisions and learn from their experiences. This human-centered approach, combined with technical expertise and adaptive methodologies, forms the foundation for building successful, sustainable software systems in an increasingly complex digital world.

12장

The Architecture of Trust: Building Teams That Build Systems

A crucial insight from the book is that architecture isn't just about technical structures but also about the human relationships that create them. As Brad Appleton's email byline consistently states: "The first thing you build is trust." Without trust, teams waste time decoding ambiguous requirements rather than simply asking clarifying questions. Jerry Weinberg's story illustrates this: when an executive requested "blue" computing cabinets, staff speculated endlessly about the meaning instead of asking directly. The answer was simple-blue was his wife's favorite color-but fear prevented the question. An Agile team needs trust to ask questions openly. This requires "egoless development" where team members put personal stakes in perspective to prioritize the team's goals. The authors emphasize that team members develop expectations of each other that enable continuous improvement through informal habits rather than rigid processes. This tacit knowledge takes time to develop. Reorganizing teams for each new product wastes time as they cycle through forming, storming, and norming before reaching the performing stage. Similarly, distributing teams across locations loses the millisecond-scale feedback loops that can reduce architecture efforts from months to days. Conway's Law suggests team structure should reflect architecture, but this becomes complex with crosscutting concerns. Teams must balance alignment with market structure, physical distribution, and business structure. Whatever the organization, boundaries between teams must remain thin for effective architectural work.

애자일 소프트웨어 개발을 위한 린 아키텍처에서 더 많은 것을 얻으세요

매일 새로운 인사이트를 10만 개 이상의 레슨에서 만나보세요
단어가 강조되어 오디오와 실시간으로 동기화됩니다
내 라이브러리를 저장하고 모든 기기에서 이용하세요

13장

From Theory to Practice: Implementing Lean Architecture

The book doesn't just present theoretical concepts but provides practical guidance for implementing Lean Architecture in real-world settings. The authors offer concrete techniques for domain analysis, use case development, and code organization. For domain analysis, they recommend identifying commonalities and variations in the business domain, then selecting appropriate design paradigms to express these patterns. This analysis should involve domain experts who can provide insights into the stable aspects of the business. For use case development, they suggest starting with a "helicopter view" of the system's major functions, then elaborating the sunny day scenario for each use case before exploring deviations. This approach provides a structured way to understand system behavior without getting lost in details too early. For code organization, they recommend separating what the system is (domain objects) from what it does (use cases), using techniques like traits or mixins to inject behavior into objects when needed. This separation allows each aspect to evolve at its own pace. Throughout these activities, the authors emphasize the importance of collaboration between business stakeholders, developers, and testers. They argue that the most effective architecture emerges when diverse perspectives are brought together early in the process. The book's practical approach extends to its numerous code examples in multiple languages, showing how abstract concepts can be implemented in concrete ways. This connection between theory and practice makes the book particularly valuable for practitioners seeking to apply Lean and Agile principles to real-world architectural challenges.

★★★★★

애자일 소프트웨어 개발을 위한 린 아키텍처 완독을 축하합니다

100만 명 이상의 학습자가 사랑합니다

“23일째 매일 사용하고 있어요. 이제 제 일상의 한 부분이 되었습니다.”

jayallen

애자일 소프트웨어 개발을 위한 린 아키텍처의 핵심 주제

lean software architecture
agile design principles
cross-functional collaboration
waste reduction
system form vs function

애자일 소프트웨어 개발을 위한 린 아키텍처의 명언

Architecture and agility are partners, not adversaries.
Architecture should focus primarily on capturing the stable aspects of system form.
The waste in software development isn't primarily from writing unnecessary code.
A good problem definition serves as a compass for development.
The process of discussing and defining the problem is often more valuable.

애자일 소프트웨어 개발을 위한 린 아키텍처의 등장인물

James O. CoplienCo-author and software architecture expert
Gertrud BjørnvigCo-author and agile development specialist
Harry GrinnellPostal worker and craftsman used as a case study
Diana VelascoArchitect who provided a user observation example

저자 소개

Lean Architecture: for Agile Software Development의 저자인 제임스 O. 코플리엔(James O. Coplien)과 거트루드 비외른빅(Gertrud Bjørnvig)은 애자일 방법론과 소프트웨어 시스템 설계 분야의 선구적인 인물들입니다. 소프트웨어 산업의 개척자인 코플리엔은 힐사이드 그룹(Hillside Group)을 공동 설립했으며, 스크럼(Scrum)과 익스트림 프로그래밍(XP)에 영감을 준 조직 패턴을 창안했습니다. 그의 영향력 있는 저서인 Advanced C++ Programming Styles and Idioms는 객체 지향 설계의 기초적인 개념들을 정립했습니다.

애자일 요구사항 전문가이자 덴마크 애자일 사용자 그룹(Danish Agile User Group)의 공동 설립자인 비외른빅은 자신의 컨설팅 회사인 Gertrud & Cope를 통해 제품 백로그와 린(Lean) 워크플로우를 최적화하는 데 20년 이상의 경력을 보유하고 있습니다.

이들의 협업은 데이터, 컨텍스트, 상호작용(DCI) 패러다임과 같은 코플리엔의 아키텍처 혁신과 마이크로소프트(Microsoft) 및 티에토에나토르(TietoEnator)에서 팀을 교육하며 얻은 비외른빅의 실무적 통찰력을 결합합니다. 이 책은 린 원칙과 애자일 구현 사이의 가교 역할을 하며, 지속 가능한 시스템 설계에 대한 그들의 공통된 관심을 반영하고 있습니다.

소프트웨어 공학계에서 널리 인용되는 Lean Architecture는 2011년 와일리(Wiley) 출판사에서 출간된 이후 학계 커리큘럼과 산업 프레임워크에서 활용되어 왔으며, 아키텍트와 애자일 실무자들을 위한 핵심 참고서로서의 입지를 굳건히 하고 있습니다.

애자일 소프트웨어 개발을 위한 린 아키텍처 요약 다운로드

애자일 소프트웨어 개발을 위한 린 아키텍처 요약을 무료 PDF 또는 EPUB으로 받으세요. 인쇄하거나 오프라인에서 언제든 읽을 수 있습니다.

다른 사용자들도 좋아한 책

Implementing lean software development

Mary Poppendieck

Lean UX

Jeff Gothelf

Software Architecture in Practice

Len Bass

Learning Agile

Andrew Stellman & Jennifer Greene

Clean Architecture

Robert C. Martin

Lean Product Playbook

Dan Olsen

Agile Project Management for Beginners

Bryan Mathis

Accelerate: The Science of Lean Software and DevOps

Nicole Forsgren

이 책에 대한 FAQ

더 알아보기

학습 계획

The Architecture of Choice

This plan is essential for professionals and individuals looking to master the psychological drivers of human behavior. It benefits anyone seeking to optimize their decision-making, improve social influence, and build lasting resilience through neurobiological insights.

1 h 36 m•4 섹션

학습 계획

Architecting Organizational Flow

This plan is essential for leaders and architects who need to align human behavior with systemic efficiency. It provides the tools to navigate cognitive biases and complex organizational dynamics, making it ideal for those driving structural change.

2 h•4 섹션

학습 계획

The Diagnostic for Tool Enshittification

As software platforms increasingly prioritize monetization over utility, developers must learn to identify predatory technical patterns. This guide is essential for software architects and engineers who want to build resilient stacks and avoid becoming locked into decaying ecosystems.

1 h 30 m•3 섹션

학습 계획

The Conqueror’s Code: Strategic Leadership

In an era of constant disruption, traditional management is no longer enough to sustain growth. This plan is designed for aspiring executives and entrepreneurs who need to blend bold vision with tactical agility and robust governance to build lasting organizations.

1 h 30 m•3 섹션

학습 계획

How to build habits.

In an era of constant distraction, mastering behavior architecture is the ultimate competitive advantage. This plan is designed for professionals and individuals seeking to replace friction with flow by leveraging neuroscience and systematic design.

4 h 57 m•4 섹션

학습 계획

Information Architecture for New Apps

Strong information architecture is the foundation of any successful digital product, ensuring users can navigate complex data with ease. This plan is ideal for product designers and developers who want to master mobile-specific patterns and validate their logic before committing to high-fidelity designs.

2 h•4 섹션

학습 계획

Master Conceptual Tech for Expert Vibecoding

This plan is designed for developers who want to move beyond syntax and master the underlying philosophy of software creation. It is ideal for engineers seeking to bridge the gap between technical execution and high-level architectural intuition.

5 h 59 m•4 섹션

학습 계획

Designing and Programming Software

This comprehensive path is designed for developers looking to transition from writing scripts to engineering robust, production-ready systems. It provides the essential bridge between basic syntax and complex architectural decision-making required in modern tech roles.

5 h 53 m•4 섹션

샌프란시스코에서 컬럼비아 대학교 동문들이 만들었습니다

LOVED BY

1,000,000+ curious minds.

4.7

avg rating

1M+ learners

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

웹에서 BeFreed가 어떻게 논의되고 있는지 더 보기

샌프란시스코에서 컬럼비아 대학교 동문들이 만들었습니다

LOVED BY

1,000,000+ curious minds.

4.7

avg rating

1M+ learners

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

웹에서 BeFreed가 어떻게 논의되고 있는지 더 보기

지금 바로 학습 여정을 시작하세요

4장

애자일 소프트웨어 개발을 위한 린 아키텍처

개요애자일 소프트웨어 개발을 위한 린 아키텍처 개요

한 권의 책, 다양한 듣기 방식.

Reimagining Software Architecture for the Agile Age

Architecture and Agility: Partners, Not Adversaries

들리는 모든 단어를 눈으로 확인하세요

The Lean Secret: Everybody, All Together, Early On

Problem Definition: The Compass for Development

애자일 소프트웨어 개발을 위한 린 아키텍처에서 더 많은 것을 얻으세요

Domain Models: The Architectural Foundation

From User Stories to Use Cases: Capturing System Behavior

들리는 모든 단어를 눈으로 확인하세요

The DCI Architecture: Bridging Mental Models and Code

MVC-U: Connecting Users to Systems

애자일 소프트웨어 개발을 위한 린 아키텍처에서 더 많은 것을 얻으세요

Documentation in the Lean and Agile World

Balancing BUFD and YAGNI

들리는 모든 단어를 눈으로 확인하세요

Conclusion: The Human Element in Software Architecture

The Architecture of Trust: Building Teams That Build Systems

애자일 소프트웨어 개발을 위한 린 아키텍처에서 더 많은 것을 얻으세요

From Theory to Practice: Implementing Lean Architecture

애자일 소프트웨어 개발을 위한 린 아키텍처 완독을 축하합니다

애자일 소프트웨어 개발을 위한 린 아키텍처의 핵심 주제

애자일 소프트웨어 개발을 위한 린 아키텍처의 명언

애자일 소프트웨어 개발을 위한 린 아키텍처의 등장인물

저자 소개

애자일 소프트웨어 개발을 위한 린 아키텍처 요약 다운로드

다른 사용자들도 좋아한 책

이 책에 대한 FAQ

What is Lean Architecture by James O. Coplien about?

Who should read Lean Architecture by James O. Coplien?

Is Lean Architecture by James O. Coplien worth reading?

What are the key principles of Lean Architecture?

더 알아보기

1,000,000+ curious minds.

1,000,000+ curious minds.

한 권의 책, 다양한 듣기 방식.

Reimagining Software Architecture for the Agile Age

Architecture and Agility: Partners, Not Adversaries

들리는 모든 단어를 눈으로 확인하세요

The Lean Secret: Everybody, All Together, Early On

Problem Definition: The Compass for Development

애자일 소프트웨어 개발을 위한 린 아키텍처에서 더 많은 것을 얻으세요

Domain Models: The Architectural Foundation

From User Stories to Use Cases: Capturing System Behavior

들리는 모든 단어를 눈으로 확인하세요

The DCI Architecture: Bridging Mental Models and Code

MVC-U: Connecting Users to Systems

애자일 소프트웨어 개발을 위한 린 아키텍처에서 더 많은 것을 얻으세요

Documentation in the Lean and Agile World

Balancing BUFD and YAGNI

들리는 모든 단어를 눈으로 확인하세요

Conclusion: The Human Element in Software Architecture

The Architecture of Trust: Building Teams That Build Systems

애자일 소프트웨어 개발을 위한 린 아키텍처에서 더 많은 것을 얻으세요

From Theory to Practice: Implementing Lean Architecture

애자일 소프트웨어 개발을 위한 린 아키텍처 완독을 축하합니다

다른 사용자들도 좋아한 책

더 알아보기

애자일 소프트웨어 개발을 위한 린 아키텍처 개요