Domain Modeling Made Functional
Tackle Software Complexity with Domain-Driven Design and F#
by: Scott Wlaschin
Published | 2018-01-10 |
---|---|
Internal code | swdddf |
Print status | In Print |
Pages | 310 |
User level | Intermediate |
Keywords | F#, ddd, functional, NoSQL, domain, model, modelling, programming |
Related titles | Learn Functional Programming with Elixir |
ISBN | 9781680502541 |
Other ISBN |
Channel epub: 9781680505498 Channel PDF: 9781680505504 Kindle: 9781680505474 Safari: 9781680505481 Kindle: 9781680505474 |
BISACs | COM051440 COMPUTERS / Software Development & Engineering / ToolsCOM062000 COMPUTERS / Data Modeling & DesignCOM062000 COMPUTERS / Data Modeling & Design |
Highlight
You want increased customer satisfaction, faster development cycles, and less wasted work. Domain-driven design (DDD) combined with functional programming is the innovative combo that will get you there. In this pragmatic, down-to-earth guide, you’ll see how applying the core principles of functional programming can result in software designs that model real-world requirements both elegantly and concisely—often more so than an object-oriented approach. Practical examples in the open-source F# functional language, and examples from familiar business domains, show you how to apply these techniques to build software that is business-focused, flexible, and high quality.
Description
Domain-driven design is a well-established approach to designing software that ensures that domain experts and developers work together effectively to create high-quality software. This book is the first to combine DDD with techniques from statically typed functional programming. This book is perfect for newcomers to DDD or functional programming—all the techniques you need will be introduced and explained.
Model a complex domain accurately using the F# type system, creating compilable code that is also readable documentation—ensuring that the code and design never get out of sync. Encode business rules in the design so that you have “compile-time unit tests,” and eliminate many potential bugs by making illegal states unrepresentable. Assemble a series of small, testable functions into a complete use case, and compose these individual scenarios into a large-scale design. Discover why the combination of functional programming and DDD leads naturally to service-oriented and hexagonal architectures. Finally, create a functional domain model that works with traditional databases, NoSQL, and event stores, and safely expose your domain via a website or API.
Solve real problems by focusing on real-world requirements for your software.
Contents and Extracts
- Understanding the Domain
- Introducing Domain-Driven Design
- The Importance of a Shared Model
- Understanding the Domain Through Business Events
- Partitioning the Domain into Subdomains
- Creating a Solution Using Bounded Contexts
- Creating a Ubiquitous Language
- Summarizing the Concepts of Domain-Driven Design
- Wrapping Up
- Understanding the Domain
- Interview with a Domain Expert
- Fighting the Impulse to Do Database-Driven Design <b>excerpt</b>
- Fighting the Impulse to Do Class-Driven Design
- Documenting the Domain
- Diving Deeper into the Order-Taking Workflow
- Representing Complexity in Our Domain Model
- Wrapping Up
- A Functional Architecture
- Bounded Contexts as Autonomous Software Components
- Communicating Between Bounded Contexts
- Contracts Between Bounded Contexts
- Workflows Within a Bounded Context
- Code Structure Within a Bounded Context
- Wrapping Up
- What’s Next
- Introducing Domain-Driven Design
- Modeling the Domain
- Understanding Types
- Understanding Functions
- Types and Functions
- Composition of Types
- Working with F# Types
- Building a Domain Model by Composing Types
- Modeling Optional Values, Errors, and Collections
- Organizing Types in Files and Projects
- Wrapping Up
- Domain Modeling with Types
- Reviewing the Domain Model
- Seeing Patterns in a Domain Model
- Modeling Simple Values
- Modeling Complex Data <b>excerpt</b>
- Modeling Workflows with Functions
- A Question of Identity: Value Objects
- A Question of Identity: Entities
- Aggregates
- Putting It All Together
- Wrapping Up
- Integrity and Consistency in the Domain
- The Integrity of Simple Values
- Units of Measure
- Enforcing Invariants with the Type System
- Capturing Business Rules in the Type System
- Consistency
- Wrapping Up
- Modeling Workflows as Pipelines
- The Workflow Input
- Modeling an Order as a Set of States
- State Machines
- Modeling Each Step in the Workflow with Types
- Documenting Effects
- Composing the Workflow from the Steps
- Are Dependencies Part of the Design?
- The Complete Pipeline
- Long-Running Workflows
- Wrapping Up
- What’s Next
- Understanding Types
- Implementing the Model
- Understanding Functions
- Functions, Functions, Everywhere
- Functions Are Things <b>excerpt</b>
- Total Functions
- Composition
- Wrapping Up
- Implementation: Composing a Pipeline
- Working with Simple Types
- Using Function Types to Guide the Implementation
- Implementing the Validation Step
- Implementing the Rest of the Steps
- Composing the Pipeline Steps Together
- Injecting Dependencies
- Testing Dependencies
- The Assembled Pipeline
- Wrapping Up
- Implementation: Working with Errors
- Using the Result Type to Make Errors Explicit
- Working with Domain Errors
- Chaining Result-Generating Functions
- Using bind and map in Our Pipeline
- Adapting Other Kinds of Functions to the Two-Track Model
- Making Life Easier with Computation Expressions
- Monads and More
- Adding the Async Effect
- Wrapping Up
- Serialization
- Persistence vs. Serialization
- Designing for Serialization
- Connecting the Serialization Code to the Workflow
- A Complete Serialization Example
- How to Translate Domain Types to DTOs
- Wrapping Up
- Persistence
- Pushing Persistence to the Edges
- Command-Query Separation
- Bounded Contexts Must Own Their Data Storage
- Working with Document Databases
- Working with Relational Databases
- Transactions
- Wrapping Up
- Evolving a Design and Keeping It Clean
- Change 1: Adding Shipping Charges
- Change 2: Adding Support for VIP Customers
- Change 3: Adding Support for Promotion Codes
- Change 4: Adding a Business Hours Constraint
- Dealing with Additional Requirements Changes
- Wrapping Up
- Wrapping Up the Book
- Understanding Functions