Functional and Reactive Domain Modeling teaches you how to think of the domain model in terms of pure functions and how to compose them to build larger abstractions. You will start with the basics of functional programming and gradually progress to the advanced concepts and patterns that you need to know to implement complex domain models. The book demonstrates how advanced FP patterns like algebraic data types, typeclass based design, and isolation of side-effects can make your model compose for readability and verifiability.
On the subject of reactive modeling, the book focuses on higher order concurrency patterns like actors and futures. It uses the Akka framework as the reference implementation and demonstrates how advanced architectural patterns like event sourcing and CQRS can be put to great use in implementing scalable models. You will learn techniques that are radically different from the standard RDBMS based applications that are based on mutation of records. You'll also pick up important patterns like using asynchronous messaging for interaction based on non blocking concurrency and model persistence, which delivers the speed of in-memory processing along with suitable guarantees of reliability.
I= contents Debasish Ghosh Ghosh2 / Functional and Reactive Domain Modeling :doctype: book
1. Functional Domain Modeling — an introduction
1.1. What is a domain model?
1.2. Introducing Domain Driven Design
1.2.1. The Bounded Context
1.2.2. The Domain Model Elements
1.2.3. Lifecycle of a Domain Object
1.2.4. The Ubiquitous Language
1.3. Thinking Functionally
1.3.1. Ah! The Joys of Purity
1.3.2. Pure Functions Compose
1.4. Managing Side Effects
1.5. Virtues of Pure Model Elements
1.6. Reactive Domain Models
1.6.1. The 3+1 View of the Reactive Model
1.6.2. Debunking the "My Model Cannot Fail" myth
1.6.3. Being Elastic and Message-driven
1.7. Event-driven Programming
1.7.1. Events and Commands
1.7.2. Domain Events
1.8. Functional meets Reactive
1.9. Summary
1.10. References
2. Scala for Functional Domain Models
2.1. Why Scala
2.2. Static Types and Rich Domain Models
2.3. Pure Functions for Domain Behavior
2.3.1. Purity of Abstractions - Revisited
2.3.2. Other Benefits of being Referentially Transparent
2.4. Algebraic Data Types and Immutability
2.4.1. Basics — Sum Type and Product Type
2.4.2. ADTs Structure Data in the Model
2.4.3. ADTs and Pattern Matching
2.4.4. ADTs encourage Immutability
2.5. Functional in the Small, OO in the Large
2.5.1. Modules in Scala
2.6. Making Models Reactive with Scala
2.6.1. Managing as Effects
2.6.2. Managing Failures
2.6.3. Managing Latency
2.7. Summary
2.8. References
3. Designing Functional Domain Models
3.1. The Algebra of API Design
3.1.1. Why Algebraic?
3.2. Defining an Algebra for a Domain Service
3.2.1. Computation and Values
3.2.2. Composition with Computation
3.2.3. The Final Algebra of Types
3.2.4. Laws of the Algebra
3.2.5. The Interpreter for the Algebra
3.3. Patterns in the Lifecycle of a Domain Model
3.3.1. Factories — Where Objects come from
3.3.2. The Smart Constructor Idiom
3.3.3. Get Smarter with more Expressive Types
3.3.4. Aggregates with Algebraic Data Types
3.3.5. Updating Aggregates Functionally with Lenses
3.3.6. Repositories and the Timeless Art of Decoupling
3.3.7. Using Lifecycle Patterns Effectively — the major takeaways
3.4. Summary
3.5. References
4. Functional Patterns for Domain Models
4.1. Patterns — The confluence of Algebra, Functions & Types
4.1.1. Mining Patterns in a Domain Model
4.1.2. The Monoid Pattern — Making Domain Models Parametric
4.2. Three basic Patterns of Computation in Typed Functional Programming
4.2.1. Functors — the pattern to build on
4.2.2. The Applicative Functor Pattern
4.2.3. Monadic Effects — A variant on Applicative Pattern
4.3. How Patterns shape your domain model
4.4. Evolution of an API with Algebra, Types & Patterns
4.4.1. The Algebra — First draft
4.4.2. Refining the Algebra
4.4.3. Final Composition — Follow the Types
4.5. Tighten up domain invariants with Patterns and Types
4.5.1. A Model for Loan Processing
4.5.2. Making Illegal States Unrepresentable[49]
4.6. Summary
4.7. References
5. Modularization of Domain Models
5.1. Modularizing your Domain Model
5.2. Modular Domain Models — A Case Study
5.2.1. Anatomy of a Module
5.2.2. Composition of Modules
5.2.3. Physical Organization of Modules
5.2.4. Modularity Leads To Compositionality
5.2.5. Modularity in Domain Models — The major takeaways
5.3. Type Class Pattern — Modularizing Polymorphic Behaviors
5.4. Aggregate Modules at Bounded Context
5.4.1. Modules and Bounded Context
5.4.2. Communication between Bounded Contexts
5.5. Another Pattern for Modularization — Free Monads[60]
5.5.1. The Account Repository
5.5.2. Making It Free
5.5.3. Account Repository — Monads for Free
5.5.4. Interpreters for Free Monads
5.5.5. Dissecting a Free Monad Implementation[66]
5.5.6. Free Monads — The Takeaways
5.6. Summary
5.7. References
6. Being Reactive
6.1. Reactive Domain Models
6.2. Non blocking API Design with Futures
6.2.1. Asynchrony as a Stackable Effect
6.2.2. Monad Transformer based Implementation
6.2.3. Reducing Latency with Parallel Fetch — A Reactive Pattern
6.2.4. Using scalaz.concurrent.Task as the Reactive construct
6.3. Explicit Asynchronous Messaging
6.4. The Stream Model
6.4.1. A Sample Use Case
6.4.2. A Graph as a Domain Pipeline
6.4.3. Backpressure Handling
6.5. The Actor Model
6.5.1. Domain Models and Actors
6.6. Summary
6.7. References
7. Modeling with Reactive Streams
7.1. The Reactive Stream Model
7.2. When to use the Stream Model
7.3. The Domain Use Case
7.4. Stream based Domain Interaction
7.5. Implementation: Front Office
7.6. Implementation: The Back Office
7.7. Major Takeaways from the Stream Model
7.8. Making Models Resilient
7.8.1. Supervision with Akka Streams
7.8.2. Clustering for Redundancy
7.8.3. Persistence of Data
7.9. Stream-based Domain Models & the Reactive Principles
7.10. Summary
7.11. References
8. Reactive Persistence and Event Sourcing
8.1. Persistence of Domain Models
8.2. Separation of Concerns
8.2.1. The Read & Write Models of Persistence
8.2.2. Command Query Responsibility Segregation (CQRS)
8.3. Event Sourcing (events as the ground truth)
8.3.1. Commands and Events in an EventSourced Domain Model
8.3.2. Implementing CQRS + Event Sourcing
8.4. Implementing an Event Sourced Domain Model (functionally)
8.4.1. Events as First Class Entities
8.4.2. Commands as Free Monads over Events
8.4.3. Interpreters � the Hideout for all the Interesting Stuff
8.4.4. Projections � The Read Side Model
8.4.5. The Event Store
8.4.6. Summary of the Implementation
8.5. Other Models of Persistence
8.5.1. Mapping Aggregates as ADTs to the Relational Tables
8.5.2. Manipulating Data (Functionally)
8.5.3. Reactive Fetch that pipelines to Akka Streams
8.6. Summary
8.7. References
9. Testing your Domain Model
9.1. Testing your domain model
9.2. Designing testable domain models
9.2.1. Decoupling side effects
9.2.2. Custom interpreters for domain algebra
9.2.3. Parametricity and testing
9.3. xUnit based testing
9.4. Property based testing
9.4.1. Modeling properties
9.4.2. Verifying properties from our domain model
9.4.3. Data generators
9.4.4. Better than xUnit based testing?
9.5. Revisiting the algebra of your model
9.6. Summary
10. Summary — Core Thoughts & Principles
10.1. Looking back
10.2. Rehashing the core principles for functional domain modeling
10.2.1. Think in expressions
10.2.2. Abstract early, evaluate late
10.2.3. Use the least powerful abstraction that fits
10.2.4. Publish what to do, hide how to do within combinators
10.2.5. Decouple algebra from the implementation
10.2.6. Isolate bounded contexts
10.2.7. Prefer futures to actors
10.3. Looking forward
About the Technology
Perhaps the biggest challenge a developer faces is understanding the problems that a software system needs to solve. Domain modeling is a technique for creating a conceptual map of a problem space such as a business system or a scientific application, so that the developer can write the software more efficiently. The domain model doesn't present a solution to the problem, but instead describes the attributes, roles, and relationships of the entities involved, along with the constraints of the system.
Reactive application design, which uses functional programming principles along with asynchronous non-blocking communication, promises to be a potent pattern for developing performant systems that are relatively easy to manage, maintain and evolve. Typically we call such models "reactive" because they are more responsive both to user requests and to system loads. But designing and implementing such models requires a different way of thinking. Because the core behaviors are implemented using pure functions, you can reason about the domain model just like mathematics, so your model becomes verifiable and robust.
What's inside
- Patterns for building reactive domain models
- Applying the principles of functional programming to domain modeling
- Learn how to decouple pure domain logic from side-effects
- Understanding asynchronous concurrency models and event based architecture
- Examples using Scala and Akka
About the reader
Written for developers and architects comfortable with the basic ideas of functional programming and traditional domain modeling. No prior exposure to Akka or reactive application design is expected.
About the author
Debasish Ghosh is a software architect with extensive experience in domain modeling. Debasish uses Scala and Akka in his daily work and was one of the earliest adopters of event sourcing using EventSourced, now called Akka Persistence. He's the author of DSLs in Action, published by Manning in 2010.
FREE domestic shipping on three or more pBooks