Refactoring to Functional Architecture Patterns
May 2018 • Presentation
This talk describes a Google experience of using both functional and object-oriented programming, which resulted in an architecture flavored by functional ideas.
Software Engineering Institute
Last year at SATURN I spoke about ideas from the functional programming (FP) community that are relevant to software architecture. This talk is a 45-minute experience report based on applying those ideas and represents one way to marry functional programming with traditional OO design advice.
We followed a pattern we call the Rich Service layer. It is implemented as pure functions plus a modified version of what Fowler calls an Anemic Domain Model. Historically, the Transaction Script pattern has been contrasted with the Domain Model pattern, where objects have methods expressing the business logic.
Our domain model expresses strictly defined types with as little optional data as possible, not just jumbled data bags. Our domain types are as strictly defined as possible. We check integrity at the system boundary. Compared to object-oriented programming, we don't push much behavior onto the types, which are immutable. We grew an (internal) Domain Specific Language (DSL) organically so the code reads naturally. But the DSL mainly expresses predicates on state rather than mutations. There is little business logic, which is instead in functions in the rich service layer.