Functional Domain Modeling - The ZIO 2 Way
5 likes1,124 views
The document discusses domain modeling in problem-solving and software engineering, focusing on the definition, vocabulary, and structures of a domain model. It emphasizes the use of ZIO (a Scala library) for functional programming, detailing how to implement repositories and services that facilitate persistent object management and transaction handling. Key concepts include the separation of domain logic, the use of effects, and the benefits of a declarative service wiring through ZLayers.
![final case class Account private (
no: AccountNo,
name: AccountName,
dateOfOpen: ZonedDateTime,
//..
)
object Account {
def tradingAccount(
no: String,
name: String,
openDate: Option[ZonedDateTime],
//..
): Validation[String, Account] = { //..
private[model] def validateAccountNo(
no: String): Validation[String, AccountNo] = //..
//..
def close(
a: Account,
closeDate: ZonedDateTime
): Validation[String, Account] = { //..
}
Model definition of an entity as an algebraic data type A Module for the model containing definitions for
smart constructors, validations, and other domain
logic for the model
• Types with names derived from domain
vocabulary
• Rich semantics with newtypes,
re
fi
nement types etc. from zio-prelude
• Abstractions that compose
• Build larger abstractions - validations
for entire domain entity as a
composition of smaller validations
• Supported by zio-prelude
• Smart constructor
• Domain behaviour](https://image.slidesharecdn.com/ddd-zio2-220930152230-0ccf97a9/85/Functional-Domain-Modeling-The-ZIO-2-Way-14-320.jpg)
![final case class Account private (
no: AccountNo,
name: AccountName,
dateOfOpen: ZonedDateTime,
//..
)
object Account {
def tradingAccount(
no: String,
name: String,
openDate: Option[ZonedDateTime],
//..
): Validation[String, Account] = { //..
private[model] def validateAccountNo(
no: String): Validation[String, AccountNo] = //..
//..
def close(
a: Account,
closeDate: ZonedDateTime
): Validation[String, Account] = { //..
}
Model definition of an entity as an algebraic data type A Module for the model containing definitions for
smart constructors, validations, and other domain
logic for the model
• Types with names derived from domain
vocabulary
• Rich semantics with newtypes,
re
fi
nement types etc. from zio-prelude
• Abstractions that compose
• Build larger abstractions - validations
for entire domain entity as a
composition of smaller validations
• Supported by zio-prelude
• Smart constructor
• Domain behaviour
•Pure model
•Functional core
•Compositional with zio-prelude](https://image.slidesharecdn.com/ddd-zio2-220930152230-0ccf97a9/85/Functional-Domain-Modeling-The-ZIO-2-Way-15-320.jpg)
![Repository
trait AccountRepository {
/** query by account number */
def queryByAccountNo(no: AccountNo): Task[Option[Account]]
/** store */
def store(a: Account): Task[Account]
/** store many */
def store(as: List[Account]): Task[Unit]
/** query by opened date */
def allOpenedOn(openedOnDate: LocalDate): Task[List[Account]]
//..
}](https://image.slidesharecdn.com/ddd-zio2-220930152230-0ccf97a9/85/Functional-Domain-Modeling-The-ZIO-2-Way-16-320.jpg)
![Repository
trait AccountRepository {
/** query by account number */
def queryByAccountNo(no: AccountNo): Task[Option[Account]]
/** store */
def store(a: Account): Task[Account]
/** store many */
def store(as: List[Account]): Task[Unit]
/** query by opened date */
def allOpenedOn(openedOnDate: LocalDate): Task[List[Account]]
//..
}
• Effectful contract
• Concrete ZIO effect (unlike tagless
fi
nal)
• Less parametric than the tagless
fi
nal approach
• No dependency on any speci
fi
c environment
• zio.Task[A] => ZIO[Any,Throwable,A]](https://image.slidesharecdn.com/ddd-zio2-220930152230-0ccf97a9/85/Functional-Domain-Modeling-The-ZIO-2-Way-17-320.jpg)
![Repository - Implementations
final case class AccountRepositoryLive(
xaResource: Resource[Task, Transactor[Task]])
extends AccountRepository {
import AccountRepositoryLive.SQL
def all: Task[List[Account]] =
xaResource.use { xa =>
SQL.getAll
.to[List]
.transact(xa)
.orDie
}
def queryByAccountNo(no: AccountNo): Task[Option[Account]] =
xaResource.use { xa =>
SQL
.get(no.value.value)
.option
.transact(xa)
.orDie
}
//..
}
• Implementation
details
• Functional core](https://image.slidesharecdn.com/ddd-zio2-220930152230-0ccf97a9/85/Functional-Domain-Modeling-The-ZIO-2-Way-18-320.jpg)
![Repository - Implementations
final case class AccountRepositoryLive(
xaResource: Resource[Task, Transactor[Task]])
extends AccountRepository {
import AccountRepositoryLive.SQL
def all: Task[List[Account]] =
xaResource.use { xa =>
SQL.getAll
.to[List]
.transact(xa)
.orDie
}
def queryByAccountNo(no: AccountNo): Task[Option[Account]] =
xaResource.use { xa =>
SQL
.get(no.value.value)
.option
.transact(xa)
.orDie
}
//..
}
object AccountRepositoryLive extends CatzInterop {
val layer: ZLayer[DBConfig, Throwable, AccountRepository] = {
ZLayer
.scoped(for {
cfg <- ZIO.service[DBConfig]
transactor <- mkTransactor(cfg)
} yield new AccountRepositoryLive(transactor))
}
//..
}
• Implementation
details
• Functional core
• ZLayer as a recipe for creating ZIO services from dependencies
• ZLayer serves as the factory for creating domain artifacts
• The scoped API ensures that resource lifetimes are properly
managed
• Inject the proper layer as dependency](https://image.slidesharecdn.com/ddd-zio2-220930152230-0ccf97a9/85/Functional-Domain-Modeling-The-ZIO-2-Way-19-320.jpg)
![Services
trait TradingService {
def getAccountsOpenedOn(openDate: LocalDate): IO[TradingError, List[Account]]
def getTrades(forAccountNo: AccountNo,
forDate: Option[LocalDate] = None
): IO[TradingError, List[Trade]]
def getTradesByISINCodes(forDate: LocalDate,
forIsins: Set[model.instrument.ISINCode]
): IO[TradingError, List[Trade]]
def orders(frontOfficeOrders: NonEmptyList[FrontOfficeOrder]
): IO[TradingError, NonEmptyList[Order]]
def execute(orders: NonEmptyList[Order],
market: Market,
brokerAccountNo: AccountNo
): IO[TradingError, NonEmptyList[Execution]]
def allocate(executions: NonEmptyList[Execution],
clientAccounts: NonEmptyList[AccountNo],
userId: UserId
): IO[TradingError, NonEmptyList[Trade]]
}
• Effectful contracts
• Concrete ZIO effect (unlike tagless
fi
nal) - clearly publishes
all exceptions and returned value types
• Less parametric than the tagless
fi
nal approach
• No dependency on any speci
fi
c environment
• zio.IO[A] => ZIO[Any, E, A]
• Coarse grained abstractions - not speci
fi
c to any entity
• All names derived from domain vocabulary](https://image.slidesharecdn.com/ddd-zio2-220930152230-0ccf97a9/85/Functional-Domain-Modeling-The-ZIO-2-Way-26-320.jpg)
![Services
trait TradingService {
def getAccountsOpenedOn(openDate: LocalDate): IO[TradingError, List[Account]]
def getTrades(forAccountNo: AccountNo,
forDate: Option[LocalDate] = None
): IO[TradingError, List[Trade]]
def getTradesByISINCodes(forDate: LocalDate,
forIsins: Set[model.instrument.ISINCode]
): IO[TradingError, List[Trade]]
def orders(frontOfficeOrders: NonEmptyList[FrontOfficeOrder]
): IO[TradingError, NonEmptyList[Order]]
def execute(orders: NonEmptyList[Order],
market: Market,
brokerAccountNo: AccountNo
): IO[TradingError, NonEmptyList[Execution]]
def allocate(executions: NonEmptyList[Execution],
clientAccounts: NonEmptyList[AccountNo],
userId: UserId
): IO[TradingError, NonEmptyList[Trade]]
}](https://image.slidesharecdn.com/ddd-zio2-220930152230-0ccf97a9/85/Functional-Domain-Modeling-The-ZIO-2-Way-27-320.jpg)
![Services
trait TradingService {
def getAccountsOpenedOn(openDate: LocalDate): IO[TradingError, List[Account]]
def getTrades(forAccountNo: AccountNo,
forDate: Option[LocalDate] = None
): IO[TradingError, List[Trade]]
def getTradesByISINCodes(forDate: LocalDate,
forIsins: Set[model.instrument.ISINCode]
): IO[TradingError, List[Trade]]
def orders(frontOfficeOrders: NonEmptyList[FrontOfficeOrder]
): IO[TradingError, NonEmptyList[Order]]
def execute(orders: NonEmptyList[Order],
market: Market,
brokerAccountNo: AccountNo
): IO[TradingError, NonEmptyList[Execution]]
def allocate(executions: NonEmptyList[Execution],
clientAccounts: NonEmptyList[AccountNo],
userId: UserId
): IO[TradingError, NonEmptyList[Trade]]
}
• Effectful contracts
• Concrete ZIO effect (unlike tagless
fi
nal) - clearly publishes
all exceptions and returned value types
• Less parametric than the tagless
fi
nal approach
• No dependency on any speci
fi
c environment
• zio.IO[A] => ZIO[Any, E, A]
• Coarse grained abstractions - not speci
fi
c to any entity
• All names derived from domain vocabulary](https://image.slidesharecdn.com/ddd-zio2-220930152230-0ccf97a9/85/Functional-Domain-Modeling-The-ZIO-2-Way-28-320.jpg)
![Services - Functional Core
final def generateTrade(
frontOfficeInput: GenerateTradeFrontOfficeInput,
userId: UserId
): IO[Throwable, NonEmptyList[Trade]] = {
for {
orders <- orders(frontOfficeInput.frontOfficeOrders)
executions <- execute(
orders,
frontOfficeInput.market,
frontOfficeInput.brokerAccountNo
)
trades <- allocate(executions, frontOfficeInput.clientAccountNos, userId)
} yield trades
}](https://image.slidesharecdn.com/ddd-zio2-220930152230-0ccf97a9/85/Functional-Domain-Modeling-The-ZIO-2-Way-29-320.jpg)
![Services - Implementation
final case class TradingServiceLive(
ar: AccountRepository,
or: OrderRepository,
er: ExecutionRepository,
tr: TradeRepository
) extends TradingService { //..
object TradingServiceLive {
val layer: ZLayer[
AccountRepository with OrderRepository with
ExecutionRepository with TradeRepository,
Nothing,
TradingServiceLive
] = ZLayer.fromFunction(TradingServiceLive.apply _)
}
• Dependencies passed as constructor arguments
• And automatically becomes part of the ZLayer and hence
part of the dependency graph
• Dependencies are interfaces only and not implementations](https://image.slidesharecdn.com/ddd-zio2-220930152230-0ccf97a9/85/Functional-Domain-Modeling-The-ZIO-2-Way-30-320.jpg)
.provide(
AccountRepositoryLive.layer,
TradingServiceLive.layer,
OrderRepositoryLive.layer,
TradeRepositoryLive.layer,
ExecutionRepositoryLive.layer,
config.live
)](https://image.slidesharecdn.com/ddd-zio2-220930152230-0ccf97a9/85/Functional-Domain-Modeling-The-ZIO-2-Way-32-320.jpg)
.provide(
AccountRepositoryLive.layer,
TradingServiceLive.layer,
OrderRepositoryLive.layer,
TradeRepositoryLive.layer,
ExecutionRepositoryLive.layer,
config.live
)
• Declarative way to build an instance of your domain
service from the speci
fi
ed dependencies
• ZLayers
- Allow automatic construction of the dependency
graph of your domain model
- Are composable
- Are asynchronous and non-blocking
- Can be acquired in parallel unlike class constructors](https://image.slidesharecdn.com/ddd-zio2-220930152230-0ccf97a9/85/Functional-Domain-Modeling-The-ZIO-2-Way-33-320.jpg)
Functional Domain Modeling - The ZIO 2 Way
- 1. Debasish Ghosh, Sep 22, 2022 Functional Domain Modeling The ZIO 2 way
- 2. What is a domain model ? A domain model in problem solving and software engineering is a conceptual model of all the topics related to a speci fi c problem. It describes the various entities, their attributes, roles, and relationships, plus the constraints that govern the problem domain. It does not describe the solutions to the problem. Wikipedia (http://en.wikipedia.org/wiki/Domain_model)
- 5. A Pattern Language for domain modeling
- 6. A Pattern Language for domain modeling •Common vocabulary
- 7. A Pattern Language for domain modeling •Common vocabulary •Modularization
- 8. • Nouns in the model • Pure objects • Names consistent with domain vocabulary • Strongly typed (newtypes, refinement types)
- 9. • Provides object storage and access • Abstractions with Effects • Names consistent with the aggregate root that gets stored • Presents clients with simple interfaces to manage persistence • Decouples model design from persistence technology
- 10. • Provides object storage and access • Abstractions with Effects • Names consistent with the aggregate root that gets stored • Presents clients with simple interfaces to manage persistence • Decouples model design from persistence technology Client code ignores repository implementation, developers do not - Eric Evans in the DDD blue book
- 11. • Coarse grained abstractions • Relates to domain concept not specific to a single entity • Interface defined in terms of other elements of the model • Abstractions with Effects
- 12. A Pattern Language for domain modeling
- 13. final case class Account private ( no: AccountNo, name: AccountName, dateOfOpen: ZonedDateTime, //.. ) Model definition of an entity as an algebraic data type • Types with names derived from domain vocabulary • Rich semantics with newtypes, re fi nement types etc. from zio-prelude
- 14. final case class Account private ( no: AccountNo, name: AccountName, dateOfOpen: ZonedDateTime, //.. ) object Account { def tradingAccount( no: String, name: String, openDate: Option[ZonedDateTime], //.. ): Validation[String, Account] = { //.. private[model] def validateAccountNo( no: String): Validation[String, AccountNo] = //.. //.. def close( a: Account, closeDate: ZonedDateTime ): Validation[String, Account] = { //.. } Model definition of an entity as an algebraic data type A Module for the model containing definitions for smart constructors, validations, and other domain logic for the model • Types with names derived from domain vocabulary • Rich semantics with newtypes, re fi nement types etc. from zio-prelude • Abstractions that compose • Build larger abstractions - validations for entire domain entity as a composition of smaller validations • Supported by zio-prelude • Smart constructor • Domain behaviour
- 15. final case class Account private ( no: AccountNo, name: AccountName, dateOfOpen: ZonedDateTime, //.. ) object Account { def tradingAccount( no: String, name: String, openDate: Option[ZonedDateTime], //.. ): Validation[String, Account] = { //.. private[model] def validateAccountNo( no: String): Validation[String, AccountNo] = //.. //.. def close( a: Account, closeDate: ZonedDateTime ): Validation[String, Account] = { //.. } Model definition of an entity as an algebraic data type A Module for the model containing definitions for smart constructors, validations, and other domain logic for the model • Types with names derived from domain vocabulary • Rich semantics with newtypes, re fi nement types etc. from zio-prelude • Abstractions that compose • Build larger abstractions - validations for entire domain entity as a composition of smaller validations • Supported by zio-prelude • Smart constructor • Domain behaviour •Pure model •Functional core •Compositional with zio-prelude
- 16. Repository trait AccountRepository { /** query by account number */ def queryByAccountNo(no: AccountNo): Task[Option[Account]] /** store */ def store(a: Account): Task[Account] /** store many */ def store(as: List[Account]): Task[Unit] /** query by opened date */ def allOpenedOn(openedOnDate: LocalDate): Task[List[Account]] //.. }
- 17. Repository trait AccountRepository { /** query by account number */ def queryByAccountNo(no: AccountNo): Task[Option[Account]] /** store */ def store(a: Account): Task[Account] /** store many */ def store(as: List[Account]): Task[Unit] /** query by opened date */ def allOpenedOn(openedOnDate: LocalDate): Task[List[Account]] //.. } • Effectful contract • Concrete ZIO effect (unlike tagless fi nal) • Less parametric than the tagless fi nal approach • No dependency on any speci fi c environment • zio.Task[A] => ZIO[Any,Throwable,A]
- 18. Repository - Implementations final case class AccountRepositoryLive( xaResource: Resource[Task, Transactor[Task]]) extends AccountRepository { import AccountRepositoryLive.SQL def all: Task[List[Account]] = xaResource.use { xa => SQL.getAll .to[List] .transact(xa) .orDie } def queryByAccountNo(no: AccountNo): Task[Option[Account]] = xaResource.use { xa => SQL .get(no.value.value) .option .transact(xa) .orDie } //.. } • Implementation details • Functional core
- 19. Repository - Implementations final case class AccountRepositoryLive( xaResource: Resource[Task, Transactor[Task]]) extends AccountRepository { import AccountRepositoryLive.SQL def all: Task[List[Account]] = xaResource.use { xa => SQL.getAll .to[List] .transact(xa) .orDie } def queryByAccountNo(no: AccountNo): Task[Option[Account]] = xaResource.use { xa => SQL .get(no.value.value) .option .transact(xa) .orDie } //.. } object AccountRepositoryLive extends CatzInterop { val layer: ZLayer[DBConfig, Throwable, AccountRepository] = { ZLayer .scoped(for { cfg <- ZIO.service[DBConfig] transactor <- mkTransactor(cfg) } yield new AccountRepositoryLive(transactor)) } //.. } • Implementation details • Functional core • ZLayer as a recipe for creating ZIO services from dependencies • ZLayer serves as the factory for creating domain artifacts • The scoped API ensures that resource lifetimes are properly managed • Inject the proper layer as dependency
- 20. REPOSITORIES have many advantages, including the following: • They present clients with a simple model for obtaining persistent objects and managing their life cycle. • They decouple application and domain design from persistence technology, multiple database strategies, or even multiple data sources • They communicate design decisions about object access • They allow easy substitution of dummy implementation, for use in testing (typically using an in-memory allocation) - Eric Evans (The Blue DDD book)
- 21. REPOSITORIES have many advantages, including the following: • They present clients with a simple model for obtaining persistent objects and managing their life cycle. • They decouple application and domain design from persistence technology, multiple database strategies, or even multiple data sources • They communicate design decisions about object access • They allow easy substitution of dummy implementation, for use in testing (typically using an in-memory allocation) - Eric Evans (The Blue DDD book) Single interface principle with return types that abstract the value as well as handling of failures through zio effects
- 22. REPOSITORIES have many advantages, including the following: • They present clients with a simple model for obtaining persistent objects and managing their life cycle. • They decouple application and domain design from persistence technology, multiple database strategies, or even multiple data sources • They communicate design decisions about object access • They allow easy substitution of dummy implementation, for use in testing (typically using an in-memory allocation) - Eric Evans (The Blue DDD book) Single interface principle with return types that abstract the value as well as handling of failures through zio effects Allow multiple implementations (the OO way) that can be injected dynamically and compositionally through ZLayers
- 23. REPOSITORIES have many advantages, including the following: • They present clients with a simple model for obtaining persistent objects and managing their life cycle. • They decouple application and domain design from persistence technology, multiple database strategies, or even multiple data sources • They communicate design decisions about object access • They allow easy substitution of dummy implementation, for use in testing (typically using an in-memory allocation) - Eric Evans (The Blue DDD book) Single interface principle with return types that abstract the value as well as handling of failures through zio effects Allow multiple implementations (the OO way) that can be injected dynamically and compositionally through ZLayers The concrete zio effect that gets returned clearly indicates semantics of failure handling, environment dependencies (if any) and the exception types
- 24. REPOSITORIES have many advantages, including the following: • They present clients with a simple model for obtaining persistent objects and managing their life cycle. • They decouple application and domain design from persistence technology, multiple database strategies, or even multiple data sources • They communicate design decisions about object access • They allow easy substitution of dummy implementation, for use in testing (typically using an in-memory allocation) - Eric Evans (The Blue DDD book) Single interface principle with return types that abstract the value as well as handling of failures through zio effects Allow multiple implementations (the OO way) that can be injected dynamically and compositionally through ZLayers The concrete zio effect that gets returned clearly indicates semantics of failure handling, environment dependencies (if any) and the exception types ZLayers! ZLayers!
- 26. Services trait TradingService { def getAccountsOpenedOn(openDate: LocalDate): IO[TradingError, List[Account]] def getTrades(forAccountNo: AccountNo, forDate: Option[LocalDate] = None ): IO[TradingError, List[Trade]] def getTradesByISINCodes(forDate: LocalDate, forIsins: Set[model.instrument.ISINCode] ): IO[TradingError, List[Trade]] def orders(frontOfficeOrders: NonEmptyList[FrontOfficeOrder] ): IO[TradingError, NonEmptyList[Order]] def execute(orders: NonEmptyList[Order], market: Market, brokerAccountNo: AccountNo ): IO[TradingError, NonEmptyList[Execution]] def allocate(executions: NonEmptyList[Execution], clientAccounts: NonEmptyList[AccountNo], userId: UserId ): IO[TradingError, NonEmptyList[Trade]] } • Effectful contracts • Concrete ZIO effect (unlike tagless fi nal) - clearly publishes all exceptions and returned value types • Less parametric than the tagless fi nal approach • No dependency on any speci fi c environment • zio.IO[A] => ZIO[Any, E, A] • Coarse grained abstractions - not speci fi c to any entity • All names derived from domain vocabulary
- 27. Services trait TradingService { def getAccountsOpenedOn(openDate: LocalDate): IO[TradingError, List[Account]] def getTrades(forAccountNo: AccountNo, forDate: Option[LocalDate] = None ): IO[TradingError, List[Trade]] def getTradesByISINCodes(forDate: LocalDate, forIsins: Set[model.instrument.ISINCode] ): IO[TradingError, List[Trade]] def orders(frontOfficeOrders: NonEmptyList[FrontOfficeOrder] ): IO[TradingError, NonEmptyList[Order]] def execute(orders: NonEmptyList[Order], market: Market, brokerAccountNo: AccountNo ): IO[TradingError, NonEmptyList[Execution]] def allocate(executions: NonEmptyList[Execution], clientAccounts: NonEmptyList[AccountNo], userId: UserId ): IO[TradingError, NonEmptyList[Trade]] }
- 28. Services trait TradingService { def getAccountsOpenedOn(openDate: LocalDate): IO[TradingError, List[Account]] def getTrades(forAccountNo: AccountNo, forDate: Option[LocalDate] = None ): IO[TradingError, List[Trade]] def getTradesByISINCodes(forDate: LocalDate, forIsins: Set[model.instrument.ISINCode] ): IO[TradingError, List[Trade]] def orders(frontOfficeOrders: NonEmptyList[FrontOfficeOrder] ): IO[TradingError, NonEmptyList[Order]] def execute(orders: NonEmptyList[Order], market: Market, brokerAccountNo: AccountNo ): IO[TradingError, NonEmptyList[Execution]] def allocate(executions: NonEmptyList[Execution], clientAccounts: NonEmptyList[AccountNo], userId: UserId ): IO[TradingError, NonEmptyList[Trade]] } • Effectful contracts • Concrete ZIO effect (unlike tagless fi nal) - clearly publishes all exceptions and returned value types • Less parametric than the tagless fi nal approach • No dependency on any speci fi c environment • zio.IO[A] => ZIO[Any, E, A] • Coarse grained abstractions - not speci fi c to any entity • All names derived from domain vocabulary
- 29. Services - Functional Core final def generateTrade( frontOfficeInput: GenerateTradeFrontOfficeInput, userId: UserId ): IO[Throwable, NonEmptyList[Trade]] = { for { orders <- orders(frontOfficeInput.frontOfficeOrders) executions <- execute( orders, frontOfficeInput.market, frontOfficeInput.brokerAccountNo ) trades <- allocate(executions, frontOfficeInput.clientAccountNos, userId) } yield trades }
- 30. Services - Implementation final case class TradingServiceLive( ar: AccountRepository, or: OrderRepository, er: ExecutionRepository, tr: TradeRepository ) extends TradingService { //.. object TradingServiceLive { val layer: ZLayer[ AccountRepository with OrderRepository with ExecutionRepository with TradeRepository, Nothing, TradingServiceLive ] = ZLayer.fromFunction(TradingServiceLive.apply _) } • Dependencies passed as constructor arguments • And automatically becomes part of the ZLayer and hence part of the dependency graph • Dependencies are interfaces only and not implementations
- 31. Services
- 32. Wiring up .. ZIO .serviceWithZIO[TradingService](service => //..) .provide( AccountRepositoryLive.layer, TradingServiceLive.layer, OrderRepositoryLive.layer, TradeRepositoryLive.layer, ExecutionRepositoryLive.layer, config.live )
- 33. Wiring up .. ZIO .serviceWithZIO[TradingService](service => //..) .provide( AccountRepositoryLive.layer, TradingServiceLive.layer, OrderRepositoryLive.layer, TradeRepositoryLive.layer, ExecutionRepositoryLive.layer, config.live ) • Declarative way to build an instance of your domain service from the speci fi ed dependencies • ZLayers - Allow automatic construction of the dependency graph of your domain model - Are composable - Are asynchronous and non-blocking - Can be acquired in parallel unlike class constructors
- 34. Entities Value Objects <<pure>> • pure • functional • statically typed • use zio-prelude for newtypes, re fi nement types, validations etc.
- 35. Entities Value Objects <<pure>> Repositories <<interfaces>> Implementations • pure • functional • statically typed • use zio-prelude for newtypes, re fi nement types, validations etc. • plain old scala traits • one per aggregate root • effectual contracts • concrete zio effects • persistence platform dependent • pass dependencies as constructor arguments • can be multiple for a single contract
- 36. Entities Value Objects <<pure>> Repositories <<interfaces>> Implementations Domain Services Domain Service Implementations <<interfaces>> • pure • functional • statically typed • use zio-prelude for newtypes, re fi nement types, validations etc. • plain old scala traits • one per aggregate root • effectual contracts • concrete zio effects • persistence platform dependent • pass dependencies as constructor arguments • can be multiple for a single contract • coarse grained • can interact with multiple domain entities • effectual contracts • concrete zio effects • pass dependencies as constructor arguments • depends only on repository interfaces and NOT implementations
- 37. Entities Value Objects <<pure>> Repositories <<interfaces>> Implementations Domain Services Domain Service Implementations <<interfaces>> Application • pure • functional • statically typed • use zio-prelude for newtypes, re fi nement types, validations etc. • plain old scala traits • one per aggregate root • effectual contracts • concrete zio effects • persistence platform dependent • pass dependencies as constructor arguments • can be multiple for a single contract • coarse grained • can interact with multiple domain entities • effectual contracts • concrete zio effects • pass dependencies as constructor arguments • depends only on repository interfaces and NOT implementations • ZLayer magic!
- 38. Entities Value Objects <<pure>> Repositories <<interfaces>> Implementations Domain Services Domain Service Implementations <<interfaces>> Application • pure • functional • statically typed • use zio-prelude for newtypes, re fi nement types, validations etc. • plain old scala traits • one per aggregate root • effectual contracts • concrete zio effects • persistence platform dependent • pass dependencies as constructor arguments • can be multiple for a single contract • coarse grained • can interact with multiple domain entities • effectual contracts • concrete zio effects • pass dependencies as constructor arguments • depends only on repository interfaces and NOT implementations • ZLayer magic!
- 39. Questions ?