Refactoring to Functional Architecture Patterns George Fairbanks - - PowerPoint PPT Presentation

▶
refactoring to functional architecture patterns
SMART_READER_LITE
LIVE PREVIEW

Refactoring to Functional Architecture Patterns George Fairbanks - - PowerPoint PPT Presentation

Sep 16, 2023 129 likes •541 views

Refactoring to Functional Architecture Patterns George Fairbanks SATURN 2018 9 May 2018 1 This talk Talk last year at SATURN: Functional Programming Invades Architecture Ideas from the functional programming (FP) community

slide-1
SLIDE 1

Refactoring to Functional Architecture Patterns

George Fairbanks SATURN 2018 9 May 2018

1

slide-2
SLIDE 2

This talk

Talk last year at SATURN:

  • Functional Programming Invades Architecture
  • Ideas from the functional programming (FP) community
  • Relevant to software architecture

Today’s talk:

  • Experience report based on applying those ideas
  • Joins FP and OO design

2

slide-3
SLIDE 3

Boring slides (repeated from last year) about an interesting topic

Big ideas in Functional Programming

3

slide-4
SLIDE 4

Function composition

4

  • Build programs by combining small functions

g(f(x)) or f(x) |> g(x)

  • Seen in pipelines, event-based systems, machine learning systems, reactive

ls | grep “foo” | uniq | sort

Note: We’re just covering the FP ideas that seem relevant to architecture

Function composition | Pure functions | Statelessness / Immutability | Idempotence | Declarativeness

slide-5
SLIDE 5

Pure functions, no side effects

  • Calling function with same params always yields same answer
  • So: Reasoning about the outcome is easier

curl http://localhost/numberAfter/5 → [always 6] curl http://localhost/customer/5/v1 → [always v1 of customer] vs curl http://localhost/customer/5 → [may be different]

5

Function composition | Pure functions | Statelessness / Immutability | Idempotence | Declarativeness

slide-6
SLIDE 6

Statelessness and Immutability

Statelessness

  • If there’s no state:
  • Easy to reason about
  • All instances are equivalent

6

Immutability

  • If you have state, but it never changes:
  • Easy to reason about
  • Concurrent access is safe

Function composition | Pure functions | Statelessness / Immutability | Idempotence | Declarativeness

slide-7
SLIDE 7

Idempotence

  • Idempotence: get the same answer regardless of how many times you do it

resizeTo100px(image) vs shrinkByHalf(image)

  • Often hard to guarantee something is done exactly once
  • Eg: Is the task stalled or failed?

○ Go ahead and schedule it again without fear that you’ll get a duplicate result

7

Function composition | Pure functions | Statelessness / Immutability | Idempotence | Declarativeness

slide-8
SLIDE 8

Declarative, not imperative

  • Define what something *is*

… or how it relates to other things

  • Versus

○ Series of operations that yield desired state

  • Definition, not procedure

8

Function composition | Pure functions | Statelessness / Immutability | Idempotence | Declarativeness

slide-9
SLIDE 9

Declarative, not imperative

Example: how much paint do I need? while(!done) { fence.paint(); } Versus: float paintNeeded(float len, float wid) { float coverage = 0.52; return len * wid * coverage; }

9

Function composition | Pure functions | Statelessness / Immutability | Idempotence | Declarativeness

How much paint do I need?

slide-10
SLIDE 10

We need to go deeper

10

slide-11
SLIDE 11

Immutable models

@Autovalue public abstract class Customer { String getName(); static Customer of(String name) { return new Autovalue_Customer(name); } } ... Customer ann = Customer.of(“Ann Smith”); Product car = Car.of(“Mustang”, 500); Sale sale1 = Sale.of(car, ann);

11

Also: Make illegal states unrepresentable

Yaron Minsky, Make illegal states unrepresentable. 2011.

slide-12
SLIDE 12

Expressions vs statements

ImmutableList<Integer> primes = ImmutableList.of(2, 3, 5); private static final ImmutableList<Integer> PRIMES = ImmutableList.builder() .add(2) .add(3) .add(5) .build();

12

List<Integer> primes = new ArrayList<>(); primes.add(2); primes.add(3); primes.add(5); Statements Expressions

slide-13
SLIDE 13

Fluent streams / collection pipeline

ImmutableList<Customer> premiumCustomers = customers.stream() .filter(customer -> customer.isPremium()) .collect(toImmutableList());

Martin Fowler, Collection Pipeline https://martinfowler.com/articles/collection-pipeline, 2014

13

slide-14
SLIDE 14

Fluent streams / collection pipeline

ImmutableList<Customer> premiumCustomers = customers.stream() .filter(Customer::isPremium) .collect(toImmutableList());

Martin Fowler, Collection Pipeline https://martinfowler.com/articles/collection-pipeline, 2014

14

slide-15
SLIDE 15

Build up a DSL

/** Returns true iff customer buys a lot. */ boolean isPremium(Customer c) { return 5 < allSales.stream() .filter(sale -> sale.customer().equals(c)) .count(); }

15

slide-16
SLIDE 16

Build up a DSL (2)

/** Returns true iff customer buys a lot. */ boolean isPremium(Customer c) { return PREMIUM_THRESHOLD < allSales.stream() .filter(sale -> sale.customer().equals(c)) .count(); }

16

slide-17
SLIDE 17

Build up a DSL (3)

/** Returns true iff customer buys a lot. */ boolean isPremium(Customer c) { return PREMIUM_THRESHOLD < salesCount(c); } /** Returns the number of sales made by customer. */ boolean salesCount(Customer c) { return allSales.stream() .filter(sale -> sale.customer().equals(c)) .count(); }

See ‘definition’, ‘designation’, ‘narrow bridge’ in Michael Jackson’s Software Requirements and Specifications. Buy it now.

17

slide-18
SLIDE 18

Domain model and DSL

  • Advice: Grow a DSL organically so the code reads naturally

○ Verbose or awkward code → refactor ○ PREMIUM_THRESHOLD < salesCount(customer)

  • Some domains are well sorted out already

○ Eg everyone knows banking has accounts, debits, credits, transactions, etc. ○ Other domains are invented with the application, in part by the developers

18

slide-19
SLIDE 19

Problem and solution domains

  • Code expresses a combination of the problem domain and the solution domain

○ Eg customers (problem) and relational tables (solution)

  • For IT code, expressions in the code should lean towards the domain

○ It's possible that you need a spin lock in your IT application, but it shouldn't be the first thing I see in the code

19

slide-20
SLIDE 20

Problem and solution domains

Problem domain

  • Customer
  • Product
  • Sale

20

Solution domain

  • ListCustomersRequest,

ListCustomersResponse

  • CustomerProto
  • ProductProto
slide-21
SLIDE 21

Parsing at system boundary

Problem domain

  • Customer
  • Product
  • Sale

Guava Converter interface

21

Solution domain

  • ListCustomersRequest,

ListCustomersResponse

  • CustomerProto
  • ProductProto

Converters between domains

  • Converter<Customer, CustomerProto>
  • Converter<Product, ProductProto>

No protos in here

slide-22
SLIDE 22

Domain model and DSL

The domain model is a domain-specific language (DSL) that has:

  • Predicates on state

(eg isPremium)

  • Query methods

(eg salesCount)

  • Transformations (pure functions)

Probably an Anemic Domain Model

22

It does NOT have:

  • Mutation
  • Business logic

(that is in the Rich Service Layer)

slide-23
SLIDE 23

Rich service layer pattern

  • Old tension:

○ Transaction Script pattern ○ Domain Model pattern

  • We followed a pattern we call the Rich Service Layer

○ Pure functions on top of an Anemic Domain Model

  • Our domain model

○ Immutable; minimal optional data (ie not just data bags) ○ Strictly defined types ○ Integrity checks at system boundary ○ Less behavior than traditional OO

23

slide-24
SLIDE 24

Lookup, validate, operate

As we refactored to use Functional Programming, this pattern emerged:

  • 1. Lookup / load the needed data
  • 2. Validate it
  • 3. Operate on it

In earlier days, I would have done all of these in the domain model objects. Now, the last step is rarely in the objects -- it’s instead in a Rich Service.

24

slide-25
SLIDE 25

Monads

25

slide-26
SLIDE 26

Optional, not NULL

26

Optional<Customer> customer = customerDao.getCustomer(5); String zipCode = customer.address().zipCode().orElse(“missing”); String zipCode = customerDao.getCustomer(5) .address() .zipCode() .orElse(“missing”); Result: Essentially zero null pointer exceptions in our code.

slide-27
SLIDE 27

Try, really try

/** Returns an active customer with an address, or null. */ Customer getValidCustomer(CustomerId id) { Customer c = getCustomer(id); if (c == null) {return null;} if (c.address() == null) {return null;} if (!c.isActive()) {return null;} return c; }

27

slide-28
SLIDE 28

Try, really try

/** Returns an active customer with an address, or null. */ Customer getValidCustomer(CustomerId id) { Customer c = getCustomer(id); if (c == null) {return null;} if (c.address() == null) {return null;} if (!c.isActive()) {return null;} return c; }

28

I hate writing this code I hate reviewing this code

  • Null checks everywhere
  • Mechanics obscure the simple logic
slide-29
SLIDE 29

Try, really try

/** Returns an active customer with an address, or empty. */ Optional<Customer> getValidCustomer(CustomerId id) { Optional<Customer> c = getCustomer(id); if (c.isEmpty()) {return c;} if (!c.get().address().isPresent()) {return Optional.empty();} if (!c.get().isActive()) {return Optional.empty();} return c; }

29

slide-30
SLIDE 30

Try, really try

/** Returns an active customer with an address, or failure. */ Try<Customer> getValidCustomer(CustomerId id) { Try<Customer> c = Try.fromOptional(getCustomer(id)); if (c.isFailure()) { return c; } if (!c.get().address().isPresent()) {return Try.fail(); } if (!c.get().isActive()) {return Try.fail(); } return c; }

30

slide-31
SLIDE 31

Try, really try

/** Returns an active customer with an address, or failure. */ Try<Customer> getValidCustomer(CustomerId id) { return Try.fromOptional(getCustomer(id)) .checkState(c -> c.address().isPresent(), "no address") .checkState(c -> c.isActive(), "inactive"); }

31

slide-32
SLIDE 32

Try, really try

/** Returns an active customer with an address, or failure. */ Try<Customer> getValidCustomer(CustomerId id) { return Try.fromOptional(getCustomer(id)) .checkState(Customer::hasAddress, "no address") .checkState(Customer::isActive, "inactive"); }

32

slide-33
SLIDE 33

Try, really try

/** Returns an active customer with an address, or failure. */ Try<Customer> getValidCustomer(CustomerId id) { return Try.fromOptional(getCustomer(id)) .checkState(Customer::hasAddress, "no address") .checkState(Customer::isActive, "inactive"); }

33

I like writing this code I like reviewing this code

  • No null checks
  • Easy to see the simple logic
slide-34
SLIDE 34

The end of the boring slides

Conclusion

34

slide-35
SLIDE 35

FP helps express intent

  • Express intent better:

○ Use fluent streaming operations ○ Use DSL ○ Optional / Try

  • Grow the DSL:

○ Keep tweaking the expressiveness of your operations ○ Tests read easily when the DSL is great

  • If you can’t express intent like: salesCount(c) > PREMIUM_THRESHOLD
  • Then your DSL / domain model is weak
  • Don’t: compensate with increasingly complex FP magic

35

slide-36
SLIDE 36

Functional code smells

  • 1. Lots of built-in types like Map<Integer, String>

○ Perhaps those are CustomerId and Address in disguise

  • 2. Doubly or more nested types like List<Map<Customer, Money>>

○ Your model needs more types. Is that map an Account or a Ledger?

  • 3. Complex or tricky functional transformations

○ If you wonder “why does this work?”, your model is too simple

36

Is it legal to add to this Integer? If not, it’s not really an Integer.

slide-37
SLIDE 37

So, is any of this architecture?

37

slide-38
SLIDE 38

Summary

38

We used these ideas / patterns

  • Java8 streaming features (collection pipeline)
  • No NULLs (Optional / Try instead)
  • Domain model in immutable datatypes

(Autovalue/Lombok)

  • Make illegal states unrepresentable

+ Design by contract

  • Domain Specific Language (DSL)
  • Separate Lookup, Validation, Operation
  • Favoring declarations over procedures
  • Rich service layer (see below)
  • Parsing at system boundary

(no protos in the model)

The durable valuable parts

  • Domain model
  • Converters to/from external representations
  • DAOs to external systems / datastores

(gateway pattern)

slide-39
SLIDE 39

Further reading

George Fairbanks, Functional Programming Invades Architecture. SATURN 2017. http://www.georgefairbanks.com/blog/saturn-2017-functional-programming-invades-architecture Martin Fowler, Collection Pipeline. https://martinfowler.com/articles/collection-pipeline. 2014. Michael Jackson, Software Requirements and Specifications. 1995. https://www.goodreads.com/book/show/582861.Software_Requirements_and_Specifications. Buy it now. Guava Java library. https://github.com/google/guava. Yaron Minsky, Make illegal states unrepresentable. https://blog.janestreet.com/effective-ml-revisited. 2011.

39