Functional Design for Reference Architectures

https://nescala.io/2018/#schedule
https://scala.io/2018/talks.html#/#TOX-4454

Transcript

1. Functional Design for Reference Architecture An experience report
2. About me Jeferson David Ossa @unyagami on twitter FP Professor Developer at Seven4n
3. Context • Engineers with Java background (mostly) • Monolithic architecture • Emerging market • Increasing business complexity • Need for speed • New needs, new approaches
4. Rediscovering FP • Reducing complexity ◦ Data in => Data out ◦ Parameterize all things ◦ Type-safe ◦ Immutability • Growing complexity ◦ Apomorphisms ◦ Dynamorphisms ◦ Chronomorphisms ◦ Zygohistomorphic prepromorphisms
5. Object-Oriented Meets Functional FP Functions Functions Functions Functions Functions in the small, objects in the large OO Single responsibility Open/Close Dependency inversion Factory pattern etc.
6. Challenges • Continue delivering business value • Onboarding new team members • Lack of experts on FP • Stop doing “better Java” • Knowledge management
7. Our approach • Fine-grained control of decisions • Code/Tests as documentation • An easy to evolve artifact • Everyone in the team can contribute • A framework was not enough
8. Reference architecture “A reference architecture is a set of documents to which an interested party can refer to for best practices, common standards, specifications and patterns” - DDD - Microservices - CQRS - ADT - DSL/Tagless - Onion/Clean/Hexagonal architecture
9. Service View µ-service Ports/Adapters Domain Services Infrastructure ACL
10. Let's check out some code warning: boilerplate code ahead
11. Final thoughts • It is complex to get simple • Abstractions have complexity costs • Keep studying • Focus on people • Measures of success
12. Thank you for listening! s4n.co