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
   

   View Slide

2. About me
   Jeferson David Ossa
   @unyagami on twitter
   FP Professor
   Developer at Seven4n
   

   View Slide

3. Context
   ● Engineers with Java background (mostly)
   ● Monolithic architecture
   ● Emerging market
   ● Increasing business complexity
   ● Need for speed
   ● New needs, new approaches
   

   View Slide

4. Rediscovering FP
   ● Reducing complexity
   ○ Data in => Data out
   ○ Parameterize all things
   ○ Type-safe
   ○ Immutability
   ● Growing complexity
   ○ Apomorphisms
   ○ Dynamorphisms
   ○ Chronomorphisms
   ○ Zygohistomorphic prepromorphisms
   

   View Slide

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.
   

   View Slide

6. Challenges
   ● Continue delivering business value
   ● Onboarding new team members
   ● Lack of experts on FP
   ● Stop doing “better Java”
   ● Knowledge management
   

   View Slide

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
   

   View Slide

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
   

   View Slide

9. Service View
   µ-service
   Ports/Adapters
   Domain
   Services
   Infrastructure
   ACL
   

   View Slide

10. Let's check out some code
    warning: boilerplate code ahead
    

    View Slide

11. Final thoughts
    ● It is complex to get simple
    ● Abstractions have complexity costs
    ● Keep studying
    ● Focus on people
    ● Measures of success
    

    View Slide

12. Thank you for listening!
    s4n.co
    

    View Slide