ZIO/Core

Hello everyone in this fantastic community.

Currently, I am using ZIO as the main library for the development of an application using the Domain-Driven Design and Clean Architecture approach.

When trying to implement the ZIO module explained in https://zio.dev/docs/howto/howto_use_layers#our-first-zio-module and Chapter 18 "Advanced Dependency injection of ZIOnomicon" we realize that a trait is defined to establish the API of service, but at the same time in most of the examples and documentation available, the implementation is in the same place that trait Service that defines of contract or API, which for DDD represents two different layers, that is, the definition of the contract, interface, trait or API is declared in separate classes so that later its implementation is made for infrastructure layer in a specific technology.

Why the trait or API is together with implementación when coupling should be avoided?

So in your recommendation, it is a bit confusing because the contract, interface, the trait is together with the implementation, in DDD there are two different class, one to define API and other class to implementation?
On the other hand, when trying to use a trait to define a universal API and then extend it to define the Service class, the tag @accessible does not generate the accessors methods.

trait contractPartiesTypeServiceApi {

  trait Api[-R] {
     def getByContractPartiesTypeId(contractPartiesTypeId: Id): RIO[R, Option[ContractPartiesType]]

   def getByDescription(description: Option[String]): RIO[R, List[ContractPartiesType]]

   def getByName(name: String): RIO[R, Option[ContractPartiesType]]

   def getByValue(value: Option[String]): RIO[R, Option[ContractPartiesType]]

    def getAll: RIO[R, List[ContractPartiesType]]

    def getAll(clientId: TableDirect): RIO[R, List[ContractPartiesType]]

    }
}

 package object contractPartiesTypeService extends contractPartiesTypeServiceApi {

  type ContractPartiesTypeService = Has[ContractPartiesTypeService.Service]

  @accessor
  object ContractPartiesTypeService {

    trait Service extends Api[ContractPartiesTypeService] {}
  }
}

currently, this forces me to duplicate code to define trait Service and its methods for each implementation, when I should only define the trait or Api in one class, and then extend the API in each implementation

Do you have any recommendations?

Is it possible for @accessible to generate the methods even if the trait Service extends from another class that contains the API?