Functional and Reactive Domain Modeling
Debasish Ghosh
Foreword by: Jonas Boner
  • October 2016
  • ISBN 9781617292248
  • 320 pages
  • printed in black & white

Brings together three different tools—domain-driven design, functional programming, and reactive principles—in a practical way.

From the Foreword by Jonas Bonér, Creator of Akka

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.

About the Technology

Traditional distributed applications won't cut it in the reactive world of microservices, fast data, and sensor networks. To capture their dynamic relationships and dependencies, these systems require a different approach to domain modeling. A domain model composed of pure functions is a more natural way of representing a process in a reactive system, and it maps directly onto technologies and patterns like Akka, CQRS, and event sourcing.

About the book

Functional and Reactive Domain Modeling teaches you consistent, repeatable techniques for building domain models in reactive systems. This book reviews the relevant concepts of FP and reactive architectures and then methodically introduces this new approach to domain modeling. As you read, you'll learn where and how to apply it, even if your systems aren't purely reactive or functional. An expert blend of theory and practice, this book presents strong examples you'll return to again and again as you apply these principles to your own projects.

Table of Contents detailed table of contents

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 can't 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

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 effects

2.6.2. Managing failures

2.6.3. Managing latency

2.7. Summary

3. Designing functional domain models

3.1. The algebra of API design

3.1.1. Why an algebraic approach?

3.2. Defining an algebra for a domain service

3.2.1. Abstracting over evaluation

3.2.2. Composing abstractions

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

4. Functional patterns for domain models

4.1. Patterns—the confluence of algebra, functions, and types

4.1.1. Mining patterns in a domain model

4.1.2. Using functional patterns to make domain models parametric

4.2. 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 the applicative pattern

4.3. How patterns shape your domain model

4.4. Evolution of an API with algebra, types, and 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[67]

4.6. Summary

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 encourages 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[79]

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. Free monads—the takeaways

5.6. Summary

6. Being reactive

6.1. Reactive domain models

6.2. Nonblocking 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. Back-pressure handling

6.5. The actor model

6.5.1. Domain models and actors

6.6. Summary

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

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. Distributed CQRS — a short note

8.4.7. 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

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. Revisiting the algebra of your model

9.5. Property based testing

9.5.1. Modeling properties

9.5.2. Verifying properties from our domain model

9.5.3. Data generators

9.5.4. Better than xUnit based testing?

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

What's inside

  • Real-world libraries and frameworks
  • Establish meaningful reliability guarantees
  • Isolate domain logic from side effects
  • Introduction to reactive design patterns

About the reader

Readers should be comfortable with functional programming and traditional domain modeling. Examples use the Scala language.

About the author

Software architect Debasish Ghosh was an early adopter of reactive design using Scala and Akka. He's the author of DSLs in Action, published by Manning in 2010.

placing your order...

Don't refresh or navigate away from the page.
print book $35.99 $59.99 pBook + eBook + liveBook
Additional shipping charges may apply
Functional and Reactive Domain Modeling (print book) added to cart
continue shopping
go to cart

eBook $38.39 $47.99 3 formats + liveBook
Functional and Reactive Domain Modeling (eBook) added to cart
continue shopping
go to cart

Prices displayed in rupees will be charged in USD when you check out.
customers also reading

This book 1-hop 2-hops 3-hops

FREE domestic shipping on three or more pBooks