Towards Functional Programming through Hexagonal Architecture

Towards Functional Programming 🦄
through Hexagonal Architecture 🎯
Habla Computing + CodelyTV

Acercándonos a la Programación Funcional 🦄
a través de la Arquitectura Hexagonal 🎯
Habla Computing + CodelyTV

Text
#SCBCN18
Software Crafters Barcelona - VI Edition

Functional Programming intro based on Hexagonal Architecture
Who we are
@JavierCane@juanshac

Session goal
🤔 
Rethinking time
Reviewing different technics to solve the same problems with more modularity

👤
Domain
models
Contents
🗺Design principles
&Implementation details
🦄
Functional
Architectures
🎯
Hexagonal
Architecture
🏗
Layers
implementation
⚡
Error
Handling

🗺 Design principles > 🎯 Hexagonal Architecture
🛀 Clean Architectures

🤯 Ports & adapters
🚫

Layers & dependency rule
Infrastructure
Application
Domain

Layered Architecture
Presentation
Domain
Database

Layered vs Hexagonal
Presentation
Domain
Database
Infrastructure
Application
Domain

CONTROLLER
REPOS
MODELS
SERVICES
APPLICATION SERVICE
D
A
I
Request flow
IMPLEMENTATION
Acceptance test
Unit test Integration test

Acceptance test
CONTROLLER
REPOS
MODELS
SERVICES
APPLICATION SERVICE
D
A
I
Request flow
IMPLEMENTATION
Port
Adapter

VideoPostController
VideoRepository
VideoVideoCreator
D
A
I
DoobieMySqlVideoRepo
Acceptance test
Request flow example

VideoPostController
VideoRepository
VideoVideoCreator
D
A
I
Acceptance test
Port
Adapter
Request flow example

Domain Events, CQRS, and Event Sourcing as an optional further step

What is a functional architecture?
DSL1
DSL2
DSLN
…
🗺 Design principles > 🦄 Functional Architectures
A FUNCTIONAL LANGUAGE IS A DOMAIN-
SPECIFIC LANGUAGE FOR DEFINING
DOMAIN-SPECIFIC LANGUAGES

The DSLs of your application
• Infrastructure DSLs
• HTTP
• Databases
• Messaging
• Application-speciﬁc DSLs
• Use cases
• Repos
• …
HTTP
SERVICE DSL
SQL
REPO DSL

Are hexagonal and functional architectures like apples and oranges?
HTTP
SERVICE DSL
SQL
REPO DSL
CONTROLLER
SERVICE IMPL.
ORM
DB
ADAPTER/INTERP.
PORT/DSL

There are no exceptions • Everything is either a port or an adapter
• Every adapter implements a given port
• Adapters are implemented on top of other ports
VideoPostController
VideoRepositoryVideoRepoC
VideoCreator
HTTP

🎯
🦄
VideoPostController
VideoRepository
VideoCreator
VideoPostController
VideoRepositoryVideoRepoC
VideoCreator
HTTP

🤔 Rethinking time
🗺 Design principles

🗺 Design principles > 🤔 Rethinking time
Final goals
• Decouple from infrastructure
• Testing easiness (test doubles when testing out use cases)
• Change tolerance
• ¡Same goals!

🗺 Design principles > 🤔 Rethinking time
Differences: More decoupling and indirection levels
• Controllers:
• Consistency (APIs for all DSLs) vs. Speciﬁc needs
• Conclusion: We need industry standards. PHP-FIG as example to follow
• Application Services:
• Consistency (APIs for all DSLs) vs. Speciﬁc needs
• Reuse use case APIs in clients (e.g. user clients)

final case class Video(
id: VideoId,
title: VideoTitle,
quality: VideoQuality
)
👤 Domain models > 🎯 OOP > Video Entity

object Video {
def apply(id: String, title: String, quality: Int): Video =
Video(
VideoId(id),
VideoTitle(title),
VideoQuality(quality)
)
}
final case class Video(
id: VideoId,
title: VideoTitle,
)

object VideoQuality {
val maxQuality = 50
val minQuality = 0
}
final case class VideoQuality(value: Int) {
require(value <= maxQuality, s"Video quality value greater than $maxQuality")
require(value >= minQuality, s"Video quality value less than $minQuality")
def increase(): VideoQuality = {
if (value >= maxQuality) this
else copy(value + 1)
}
}
OOP: Data+Behaviour
👤 Domain models > 🎯 OOP > VideoQuality Value Object

val maxQuality = 50
val minQuality = 0
}
}
}
Behaviour
Simpler API
+ domain semantics
+ immutability
👤 Domain models > 🎯 OOP > VideoQuality Value Object

case class Video(
id: VideoId,
title: VideoTitle,
) {
def increaseQuality(): Video =
copy(quality = quality.increase())
}
VideoQualityIncreaser Video
increaseQuality()
Behaviour
Rich domain model - Tell don’t ask

public final class Video {
private VideoId id;
private VideoQuality quality;
// …
public VideoQuality getQuality() {
return quality;
}
public void setQuality(
VideoQuality quality
) {
this.quality = quality;
}
}
VideoQualityIncreaser Video
getQuality()
increaseQuality()
setQuality()
Behaviour

setQuality()
getQuality()
increaseQuality()
…Increaser Video
Behaviour
…Increaser Video
Behaviour
increaseQuality()

🦄 Functional Programming
👤 Domain models

…Increaser Video
Behaviour
👤 Domain models > 🦄 FP > Video Entity
increaseQuality()
…Increaser
increaseQuality()
Behaviour Video
…

def increaser[V: VideoBehaviour](
video: V): V =
video.increaseQuality()
Increaser
increaseQuality()
LOGIC
VideoBehaviour
Rich domain layer - Tell don’t ask
Do not expose quality property
👤 Domain models > 🦄 FP > Video EntityTYPE CLASSES: API
trait VideoBehaviour[T]{
val maxQuality: Int
val minQuality: Int
def increaseQuality(thing: T): T
}
+Less coupling!

PlainVideo
👤 Domain models > 🦄 FP > Video Entitycase class PlainVideo(
id: VideoId,
title: VideoTitle,
)
copy(quality=…)
quality
increase
:VideoImpl
VideoBeh
INSTANTIATION
implicit object VideoImpl
extends VideoBehaviour[PlainVideo]{
val maxQuality = 100
val minQuality = 10
def increaseQuality(video: PlainVideo) =
video.copy(quality =
video.quality.increase)
}

Video
Behaviour
👤 Domain models > 🦄 FP > Video Entitycase class Video(
id: VideoId,
title: VideoTitle,
quality: VideoQuality){
def increaseQuality(): Video =
copy(quality = quality.increase())
}
increaseQuality()
:VideoImpl
implicit object VideoImpl
extends VideoBehaviour[Video]{
val maxQuality = Video.maxQuality
def increaseQuality(video: Video) =
video.increaseQuality
}
VideoBeh
INSTANTIATION

👤 Domain models > 🦄 FP > Video Entity
COMPOSITION
def plainVideoIncreaser(video: PlainVideo): PlainVideo =
increaser[PlainVideo](video)
def videoIncreaser(video: Video): Video =
increaser[Video](video)

👤 Domain models

& Implementation > 👤 Domain models > 🤔 Rethinking time
Differences on Domain Modelling goals
• 🦄 FP Type classes: APIs with steroids
• Goal: Coupling to behaviours (not to state)
• Decouple behaviour and data
• Support rich domain layers
• 🎯 OOP: High cohesion (behaviour close to related data)
• Modularity because abstractions => More indirection levels (complexity)
• Goal: Rich domain models (data+behaviour)
INSTANTIATION
TYPECLASS: API
COMPOSITION
LOGIC

🎯 Hexagonal Architecture
🏗 Layers implementations

final class VideoPostController(creator: VideoCreator) {
def post(id: String, title: String): StandardRoute = {
creator.create(VideoId(id), VideoTitle(title))
complete(HttpResponse(Created))
}
}
VideoPostController - HTTP API Controller
VideoPostController

final class VideoCreator(
repository: VideoRepository,
publisher: MessagePublisher
) {
def create(id: VideoId, title: VideoTitle): Unit = {
val video = Video(id, title)
repository.save(video)
publisher.publish(VideoCreated(video))
}
}
VideoCreator - Application Service/Use case
VideoPostController VideoCreator

trait VideoRepository {
def all(): Future[Seq[Video]]
def save(video: Video): Future[Unit]
}
VideoRepository - Domain contract/Port
VideoPostController VideoRepositoryVideoCreator

DoobieMySqlVideoRepository - Infrastructure implementation/Adapter
VideoPostController VideoRepositoryVideoCreator
final class DoobieMySqlVideoRepository(db: DoobieDbConnection)
(implicit ec: ExecutionContext) extends VideoRepository {
override def all(): Future[Seq[Video]] =
db.read(sql”SELECT…”.query[Video].to[Seq])
override def save(video: Video): Future[Unit] =
sql"INSERT INTO…”.update.run
.transact(db.transactor)
.unsafeToFuture().map(_ => ())
}

🦄 Functional Architectures

def save(video: Video):
Future[Unit]
}
Domain contract/PortVideoRepository
?
def all(): cats.IO[Seq[Video]]
cats.IO[Unit]
}
def all(): Seq[Video]
def save(video: Video): Unit
}

def all(): Seq[Video]
def save(video: Video): Unit
}
Future[Unit]
}
def all(): cats.IO[Seq[Video]]
cats.IO[Unit]
}
Domain contract/Port
infrastructure leaks
VideoRepository
?

trait VideoRepository[P[_]] {
def all(): P[Seq[Video]]
def save(video: Video): P[Unit]
}
TYPE (CONSTRUCTOR) CLASSES
VideoRepository
?
Domain contract/Port

Infrastructure implementation/Adapter
import scala.concurent.Future
final class DoobieMySqlVideoRepoFuture(
db: DoobieDbConnection[Future])(implicit
ec: ExecutionContext) extends VideoRepository[Future] {
override def all(): Future[Seq[Video]] =
db.read(sql"SELECT ...".query[Video].to[Seq])
override def save(video: Video): Future[Unit] =
sql"INSERT INTO ... ".update.run
.map(_ => ())
}
VideoRepository
DoobieVideoRepoFuture
INSTANTIATION

Infrastructure implementation/AdapterVideoRepository
DoobieVideoRepoIO
import cats.effect.IO
final class DoobieMySqlVideoRepoIO(
db: DoobieDbConnection[IO]) extends VideoRepository[IO] {
override def all(): IO[Seq[Video]] =
db.read(sql"SELECT ...".query[Video].to[Seq])
override def save(video: Video): IO[Unit] =
sql"INSERT INTO ... ".update.run
.map(_ => ())
}
INSTANTIATION

Infrastructure implementation/AdapterVideoRepository
DoobieVideoRepo (GENERIC) INSTANTIATION
final case class DoobieMySqlVideoRepo[P[_]: Monad]()(
db: DoobieDbConnection[P]) extends VideoRepository[P] {
override def all(): P[Seq[Video]] =
db.read(sql"SELECT …”.query[Video].to[Seq])
override def save(video: Video): P[Unit] =
sql"INSERT …”.update.run
.map(_ => ())
}

Differences on layers implementation
• Same goal: Decouple from infrastructure
• 🦄 FP:
• One step forward to avoid infrastructure leaks
• Again, through type classes: a better API
• More complexity: monads, applicatives, etc.
& Implementation > 🏗 Layers > 🤔 Rethinking time

val maxQuality = 50
val minQuality = 0
}
}
}
VO: Raise exceptions
for invalid states
⚡Error Handling > 🎯 OOP > Raise exceptions

final class VideoFinder(repository: VideoRepository)
(implicit ec: ExecutionContext) {
def find(id: VideoId): Future[Video] =
repository.search(id).map { videoOption =>
if (videoOption.isEmpty) throw VideoNotFound(id)
else videoOption.get
}
}
Imperativeness
⚡Error Handling > 🎯 OOP > Raise exceptions
def search(id: VideoId): Future[Option[Video]]
}

final class VideoGetController extends ApiController
{
protected function exceptions(): array
{
return [
VideoNotFound::class => Response::HTTP_NOT_FOUND,
];
}
// …
}
HTTP Mapping
⚡Error Handling > 🎯 OOP > Handle exceptions

🦄 Functional Architectures
⚡Error Handling

Imperativeness
⚡Error Handling > 🦄 FP > Raise errors
Declarativeness
+
final case class VideoFinderRepo[P[_]]()(
implicit repository: VideoRepository[P]
) extends VideoFinder[P] {
def find(id: VideoId)(implicit
E: MonadError[P, VideoFinderError]): P[Video] =
repository.search(id) flatMap { maybeVideo =>
maybeVideo.fold(E.raiseError[Video](VideoNotFound(id))){
video => video.pure[P]
}
}
}

final case class VideoFinderRepo[P[_]]()(
}
}
}
A functional signature doesn’t hide anything!

TYPE CLASSES
trait MonadError[F[_], E] {
def raiseError[A](e: E): F[A]
def handleErrorWith[A](fa: F[A])(f: E => F[A]): F[A]
}

final case class VideoFinderRepo[P[_]: Monad]()(
}
}
}

}
}
}
Imperativeness

val maybeVideo = repository.search(id) ;
if (videoOption.isEmpty) throw VideoNotFound(id)
else videoOption.get
}
Monadic programming is
imperative programming with steroids!

object FutureBasedController{
case class VideoController(
videoFinder: VideoFinder[Future]
)(implicit ec: ExecutionContext) extends Http4sDsl[Future] {
val service = HttpService[Future] {
case GET -> Root / "videos" / id =>
videoFinder.find(VideoId(id)) flatMap {
case video =>
Ok(video.asJson)
} recoverWith {
case error: VideoNotFound =>
NotFound(error.asJson)
}
}
}
}
Future-based
HTTP Mapping
LOGIC

case class VideoController[P[_]: Effect](
videoFinder: VideoFinder[P]
) extends Http4sDsl[P] {
val service = HttpService[P] {
case GET -> Root / "videos" / id =>
videoFinder.find(VideoId(id)) flatMap {
case video =>
Ok(video.asJson)
} handleErrorWith {
case error: VideoNotFound =>
NotFound(error.asJson)
}
}
}
Generic
HTTP Mapping
MonadError
API
LOGIC

⚡Error Handling

Differences on Error handling
• 🦄 FP:
• FP tell no lies (or, rather, doesn’t hide anything): more robust contracts using
type system
• Declarative: more abstract about how the error will be raised (exceptions,
Option, Either, etc)
& Implementation > ⚡Error Handling > 🤔 Rethinking time

🍕Takeaways
⚡ Exceptions
🏗 Monolithic interfaces
👤 Rich domain models

🍕Takeaways
⚡ Exceptions
🏗 Monolithic interfaces
👤 Rich domain models
🦄 TypeClasses
⚛ APIs with steroids
🧐 FP as a subsuming paradigm

👉Formación FP presencial 👈
hablapps.com

👉Cursos en vídeo online 👈
codely.tv/pro/cursos

Towards Functional Programming through Hexagonal Architecture

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Towards Functional Programming through Hexagonal Architecture

Similar a Towards Functional Programming through Hexagonal Architecture (20)

Último

Último (20)

Towards Functional Programming through Hexagonal Architecture