Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve input domain model definition #235

Open
Josuto opened this issue May 12, 2024 · 0 comments · Fixed by #240
Open

Improve input domain model definition #235

Josuto opened this issue May 12, 2024 · 0 comments · Fixed by #240
Assignees
Labels
enhancement New feature or request

Comments

@Josuto
Copy link
Owner

Josuto commented May 12, 2024

Is your feature request related to a problem? Please describe.

Several developers have expressed that they find the current domain model map definition cumbersome and confusing, which in turn degrades Developer Experience.

The constructor of every custom repository extending MongooseRepository or MongooseTransactionalRepository must pass an object map defining a persistable domain model as input parameter to its parent constructor. This map must specify a Default domain model supertype definition and, optionally, one or more domain model subtype definitions.

The origin of the confusion is on the fact that the key of each subtype definition must match the name of a domain model subtype. Many developers are unaware of this requirement and provide an arbitrary name for such keys, causing the initialisation of their custom repository to fail.

Here is an example that illustrates the issue:

export class MongooseBookRepository
  extends MongooseRepository<Book>
  implements BookRepository
{
  constructor() {
    super({
      Default: { type: Book, schema: BookSchema },
      // Good subtype definition; the key matches the type name
      PaperBook: { type: PaperBook, schema: PaperBookSchema },
      // Bad subtype definition; the key does not match the type name
      Audio: { type: AudioBook, schema: AudioBookSchema },
    });
  }
}

Moreover, reality shows that many custom repositories encompass a domain model that includes a single type. In the previous example, MongooseBookRepository would only deal with instances of type Book. In such cases, the key Default is superfluous; super({ type: Book, schema: BookSchema }) would do.

Describe the solution you'd like

Simplify the structure of the domain model type map so that its semantics are clearer, and thus, easier. Also, it must work well for the implementation of custom repositories that encompass any single or multiple type domain model.

Describe alternatives you've considered

We have considered two approaches. The first one consists of keeping the Default key to specify supertype definition and aggregating all subtype definitions in an optional JS array. The following piece of code, that is based on the previous example, illustrates the proposal:

export class MongooseBookRepository
  extends MongooseRepository<Book>
  implements BookRepository
{
  constructor() {
    super({
      Default: { type: Book, schema: BookSchema },
      subtypes: [
        { type: PaperBook, schema: PaperBookSchema },
        { type: AudioBook, schema: AudioBookSchema }
      ]
    });
  }
}

This approach is clearer than the original and it most likely cause the least impact on custom repositories that address a single type domain model. However, such custom repositories must still explicitly declare a Default domain type definition.

An alternative to further simplify the domain model type map would consist of removing the Default key entirely and define all domain subtypes via an optional subtypes property. Consider the following example:

export class MongooseBookRepository
  extends MongooseRepository<Book>
  implements BookRepository
{
  constructor() {
    super({ 
      type: Book, 
      schema: BookSchema, 
      subtypes: [
        { type: PaperBook, schema: PaperBookSchema },
        { type: AudioBook, schema: AudioBookSchema }
      ]
    });
  }
}

This is the cleanest possible way to define a domain model, independently from its nature (standalone or composed). Furthermore, this approach enables recursive (sub)type definition, although this is a feature to be explored in the future.

Additional context

The adoption of this feature by current monguito users is to be explored. Thus, it is a great canary candidate.

@Josuto Josuto added the enhancement New feature or request label May 12, 2024
@Josuto Josuto self-assigned this May 12, 2024
@Josuto Josuto linked a pull request May 24, 2024 that will close this issue
@Josuto Josuto changed the title Improve domain model map definition Improve input domain model definition May 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant