Functional Design for Reference Architectures

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