1 reply

How to deal with schema being different in DB layer vs domain

Hi all, I'm trying to see if there is a more elegant way of doing what I'm doing.

In my app I'm trying to define all of my domain entities as

Schema.Class

Schema.Class

s. For example

export class LikeCount extends Schema.Class<LikeCount>('LikeCount')({
  count: Schema.NonNegativeInt,
  createdAt: Schema.ValidDateFromSelf,
  sourceID: Schema.Union(VideoIDSchema, PostIDSchema),
}) {}

export class LikeCount extends Schema.Class<LikeCount>('LikeCount')({
  count: Schema.NonNegativeInt,
  createdAt: Schema.ValidDateFromSelf,
  sourceID: Schema.Union(VideoIDSchema, PostIDSchema),
}) {}

You'll notice the

createdAt

createdAt

field is a

Date

Date

object. But when I persist to my database (DynamoDB), I'll need to transform that

Date

Date

object to something the database can handle. In my circumstance, a Unix timestamp is best. Right now I've written my own library for wrapping DynamoDB and is requires a

parse

parse

function for turning database rows into domain objects. This is what I currently have to do:

const LikeCountDB = vnamo.make({
  parser: flow(
    Schema.decodeUnknownSync(Schema.Struct({
      ...LikeCount.fields,
      createdAt: UnixTimestampSchema,
    })),
    // true here skips doing the validations for a second time
    x => new LikeCount(x, true),
  ),
  // ... rest of config
});

const LikeCountDB = vnamo.make({
  parser: flow(
    Schema.decodeUnknownSync(Schema.Struct({
      ...LikeCount.fields,
      createdAt: UnixTimestampSchema,
    })),
    // true here skips doing the validations for a second time
    x => new LikeCount(x, true),
  ),
  // ... rest of config
});

Is there a better way to create a new Schema that replaces a field, but ultimately creates the same domain type in the end? Or is what I have basically the expected way to pull it off?

Thank you!

How to deal with schema being different in DB layer vs domain

Hi all, I'm trying to see if there is a more elegant way of doing what I'm doing.

In my app I'm trying to define all of my domain entities as

Schema.Class

Schema.Class

s. For example

export class LikeCount extends Schema.Class<LikeCount>('LikeCount')({
  count: Schema.NonNegativeInt,
  createdAt: Schema.ValidDateFromSelf,
  sourceID: Schema.Union(VideoIDSchema, PostIDSchema),
}) {}

export class LikeCount extends Schema.Class<LikeCount>('LikeCount')({
  count: Schema.NonNegativeInt,
  createdAt: Schema.ValidDateFromSelf,
  sourceID: Schema.Union(VideoIDSchema, PostIDSchema),
}) {}

You'll notice the

createdAt

createdAt

field is a

Date

Date

object. But when I persist to my database (DynamoDB), I'll need to transform that

Date

Date

object to something the database can handle. In my circumstance, a Unix timestamp is best. Right now I've written my own library for wrapping DynamoDB and is requires a

parse

parse

function for turning database rows into domain objects. This is what I currently have to do:

const LikeCountDB = vnamo.make({
  parser: flow(
    Schema.decodeUnknownSync(Schema.Struct({
      ...LikeCount.fields,
      createdAt: UnixTimestampSchema,
    })),
    // true here skips doing the validations for a second time
    x => new LikeCount(x, true),
  ),
  // ... rest of config
});

const LikeCountDB = vnamo.make({
  parser: flow(
    Schema.decodeUnknownSync(Schema.Struct({
      ...LikeCount.fields,
      createdAt: UnixTimestampSchema,
    })),
    // true here skips doing the validations for a second time
    x => new LikeCount(x, true),
  ),
  // ... rest of config
});

Is there a better way to create a new Schema that replaces a field, but ultimately creates the same domain type in the end? Or is what I have basically the expected way to pull it off?

Thank you!

How to deal with schema being different in DB layer vs domain

Similar Threads

How to deal with schema being different in DB layer vs domain

Similar Threads

Similar Threads

Similar Threads