Prix bas
CHF71.20
Cet article manque chez l'éditeur. Il sera livré dès que possible.
Methods for managing complex software construction following the practices, principles and patterns of Domain-Driven Design with code examples in C#
This book presents the philosophy of Domain-Driven Design (DDD) in a down-to-earth and practical manner for experienced developers building applications for complex domains. A focus is placed on the principles and practices of decomposing a complex problem space as well as the implementation patterns and best practices for shaping a maintainable solution space. You will learn how to build effective domain models through the use of tactical patterns and how to retain their integrity by applying the strategic patterns of DDD. Full end-to-end coding examples demonstrate techniques for integrating a decomposed and distributed solution space while coding best practices and patterns advise you on how to architect applications for maintenance and scale.
Auteur
Scott Millett is the Director of IT for Iglu.com, and has been working with .NET since version 1.0. He was awarded the ASP.NET MVP in 2010 and 2011, and is the author of Professional ASP.NET Design Patterns and Professional Enterprise .NET. Nick Tune is a software developer delivering solutions to complex business problems using technology, collaboration, and Domain-Driven Design. He continually seeks improvement by working on ambitious products and with enthusiastic people.
Texte du rabat
Build solutions for complex business problems more effectively with Domain-Driven Design This book distills the ideas and theories of the Domain-Driven Design (DDD) philosophy into a practical playbook that you can leverage to simplify application development for complex problem domains. A focus is placed on the principles and practices of decomposing a complex problem space as well as the implementation patterns and best practices for shaping a maintainable solution space. You will learn how to build effective domain models through the use of tactical patterns and how to retain their integrity by applying the strategic patterns of DDD. Full end-to-end coding examples demonstrate techniques for integrating a decomposed and distributed solution space while coding best practices and patterns advise you on how to architect applications for maintenance and scale.
Contenu
INTRODUCTION xxxv
PART I: THE PRINCIPLES AND PRACTICES OF DOMAIN DRIVEN DESIGN
CHAPTER 1: WHAT IS DOMAIN DRIVEN DESIGN? 3
The Challenges of Creating Software for Complex Problem Domains 4
Code Created Without a Common Language 4
A Lack of Organization 5
The Ball of Mud Pattern Stifles Development 5
A Lack of Focus on the Problem Domain 6
How the Patterns of Domain Driven Design Manage Complexity 6
The Strategic Patterns of DDD 6
Distilling the Problem Domain to Reveal What Is Important 7
Creating a Model to Solve Domain Problems 7
Using a Shared Language to Enable Modeling Collaboration 7
Isolate Models from Ambiguity and Corruption 8
Understanding the Relationships between Contexts 9
The Tactical Patterns of DDD 9
The Problem Space and the Solution Space 9
The Practices and Principles of Domain Driven Design 11
Focusing on the Core Domain 11
Learning through Collaboration 11
Creating Models through Exploration and Experimentation 11
Communication 11
Understanding the Applicability of a Model 12
Constantly Evolving the Model 12
Popular Misconceptions of Domain Driven Design 12
Tactical Patterns Are Key to DDD 12
DDD Is a Framework 13
DDD Is a Silver Bullet 13
The Salient Points 13
CHAPTER 2: DISTILLING THE PROBLEM DOMAIN 15
Knowledge Crunching and Collaboration 15
Reaching a Shared Understanding through a Shared Language 16
The Importance of Domain Knowledge 17
The Role of Business Analysts 17
An Ongoing Process 17
Gaining Domain Insight with Domain Experts 18
Domain Experts vs Stakeholders 18
Deeper Understanding for the Business 19
Engaging with Your Domain Experts 19
Patterns for Effective Knowledge Crunching 19
Focus on the Most Interesting Conversations 19
Start from the Use Cases 20
Ask Powerful Questions 20
Sketching 20
Class Responsibility Collaboration Cards 21
Defer the Naming of Concepts in Your Model 21
Behavior Driven Development 22
Rapid Prototyping 23
Look at Paper Based Systems 24
Look For Existing Models 24
Understanding Intent 24
Event Storming 25
Impact Mapping 25
Understanding the Business Model 27
Deliberate Discovery 28
Model Exploration Whirlpool 29
The Salient Points 29
CHAPTER 3: FOCUSING ON THE CORE DOMAIN 31
Why Decompose a Problem Domain? 31
How to Capture the Essence of the Problem 32
Look Beyond Requirements 32
Capture the Domain Vision for a Shared Understanding of What Is Core 32
How to Focus on the Core Problem 33
Distilling a Problem Domain 34
Core Domains 35
Treat Your Core Domain as a Product Rather than a Project 36
Generic Domains 37
Supporting Domains 37
How Subdomains Shape a Solution 37
Not All Parts of a System will be Well Designed 37
Focus on Clean Boundaries over Perfect Models 38
The Core Domain Doesn't Always Have to Be Perfect the First Time 39
Build Subdomains for Replacement Rather than Reuse 39
What if You Have no Core Domain? 39
The Salient Points 40
CHAPTER 4: MODEL DRIVEN DESIGN 41
What Is a Domain Model? 42
The Domain versus the Domain Model 42
The Analysis Model 43
The Code Model 43
The Code Model Is the Primary Expression of the Domain Model 44
Model Driven Design 44
The Challenges with Upfront Design 44
Team Modeling 45
Using a Ubiquitous Language to Bind the Analysis to the Code Model 47
A Language Will Outlive Your Software 47
The Language of the Business 48
Translation between the Developers and the Business 48
Collaborating on a Ubiquitous Language 48
Carving Out a Language by Working with Concrete Examples 49
Teach Your Domain Experts to Focus on the Problem and Not Jump to a Solution 50
Best Practices for Shaping the Language 51
How to Create Effective Domain Models 52
Don't Let the Truth Get in the Way of a Good Model 52
Model Only What Is Relevant 54
Domain Models Are Temporarily Useful 54
Be Explicit with Terminology 54
Limit Your Abstractions 54
Focus Your Code at the Right Level of Abstraction 55
Abstract Behavior Not Implementations 55
Implement the Model in Code Early and Often 56
Don't Stop at t…