DEV Community

loading...

Discussion on: End-to-end Type Safety in Clean Architecture

Collapse
5422m4n profile image
Sven Assmann

Nice Post! We use a very similar architecture right now, just that we keep the GQL Schema as single source of truth and generate the typescript classes (on the client and server) from it.

So my question is, did you had any bad side effects on your domain models? Because they are annotated by TypeGraph specifics things that might lead to issues e.g. on duck type behaviour or similar?

Collapse
thekarel profile image
Charles Szilagyi Author

Thanks Sven. In my solution the source of truth is the domain model and this is pure TypeScript (no TypeGraph there). For example:

export interface Order {
  id: string
  customerName: string
  deliveryAddress: string
  items: Cupcake[]
}

The TypeGraph interfaces are the ones that are derived from the domain modules (note implements):

@ObjectType()
export class Order implements DomainOrder {
  @Field(() => ID)
  id!: string

  @Field()
  customerName!: string

  @Field()
  deliveryAddress!: string

  @Field(() => [Cupcake])
  items!: DomainCupcake[]
}

For me, this makes more sense (i.e. to derive GraphQL types from the domain) because GraphQL is just an interface to the domain. In other words, I prefer "domain first" design :)

Collapse
5422m4n profile image
Sven Assmann

Makes perfectly sense, especially when there are more external interfaces that just GQL that needs to be served by the same domain model.
There might just be the down side that the external representation and the domain model are now identical. You cannot easily have a different internal domain model / storage representation than your external GQL Model. But mostly that’s fine.

Forem Open with the Forem app