Skip to main content
Software Engineering

Return to Question

added 189 characters in body
Source Link
Jokab
Jokab
  • 141
  • 5

I was not sure how to title this question, but bear with me.

My company is building a new product and for it we will use a third-party service (let's call it ENB for short) to be responsible for many operations on our data that are not our core business. It's in .NET Core if it matters.

To illustrate I will use the entity ApplicationUser, which is the user that logs in to our application. ApplicationUser will consist of account data as well as a Person, representing the real life person that created this account. To function, ENB needs the Person object and most of its data to function, so we have to create the Person object in ENB. This puts us in a situation where if we store the Person in both our database and in ENB, we will have duplicated the data which rings all kinds of alarm bells in my head.

public class ApplicationUser
{
    public int Id { get; set; }
    < ... other fields ... >
    public int EnbPersonId { get; set; }  // This is stored in ENB
}

The above is the case for many of our entities: ENB needs their data to function so we have to store it there. For others, part of the fields of a domain object are specific to our application and parts are needed by ENB. This is why I say that the schema is split across sources.

One solution to this is to prefer storing in ENB whenever it's needed, and store the rest (as said, sometimes parts of an entity) in our database. Then, whenever a type is needed, we assemble it by querying both our own database as well as calling ENB through API (we don't have direct access to ENB's database).

Another solution is to simply duplicate the data. This instinctively feels bad because we have to update two sources whenever anything is changed, and we have to make sure they stay in sync (what happens if one update fails and the other doesn't?).

What I'm looking for is if any solution is better than the other, and if there is a name for this pattern of splitting a schema across multiple sources i.e. our own and ENB.

I was not sure how to title this question, but bear with me.

My company is building a new product and for it we will use a third-party service (let's call it ENB for short) to be responsible for many operations on our data that are not our core business. It's in .NET Core if it matters.

To illustrate I will use the entity ApplicationUser, which is the user that logs in to our application. ApplicationUser will consist of account data as well as a Person, representing the real life person that created this account. To function, ENB needs the Person object and most of its data to function, so we have to create the Person object in ENB. This puts us in a situation where if we store the Person in both our database and in ENB, we will have duplicated the data which rings all kinds of alarm bells in my head.

The above is the case for many of our entities: ENB needs their data to function so we have to store it there. For others, part of the fields of a domain object are specific to our application and parts are needed by ENB. This is why I say that the schema is split across sources.

One solution to this is to prefer storing in ENB whenever it's needed, and store the rest (as said, sometimes parts of an entity) in our database. Then, whenever a type is needed, we assemble it by querying both our own database as well as calling ENB through API (we don't have direct access to ENB's database).

Another solution is to simply duplicate the data. This instinctively feels bad because we have to update two sources whenever anything is changed, and we have to make sure they stay in sync (what happens if one update fails and the other doesn't?).

What I'm looking for is if any solution is better than the other, and if there is a name for this pattern of splitting a schema across multiple sources i.e. our own and ENB.

I was not sure how to title this question, but bear with me.

My company is building a new product and for it we will use a third-party service (let's call it ENB for short) to be responsible for many operations on our data that are not our core business. It's in .NET Core if it matters.

To illustrate I will use the entity ApplicationUser, which is the user that logs in to our application. ApplicationUser will consist of account data as well as a Person, representing the real life person that created this account. To function, ENB needs the Person object and most of its data to function, so we have to create the Person object in ENB. This puts us in a situation where if we store the Person in both our database and in ENB, we will have duplicated the data which rings all kinds of alarm bells in my head.

public class ApplicationUser
{
    public int Id { get; set; }
    < ... other fields ... >
    public int EnbPersonId { get; set; }  // This is stored in ENB
}

The above is the case for many of our entities: ENB needs their data to function so we have to store it there. For others, part of the fields of a domain object are specific to our application and parts are needed by ENB. This is why I say that the schema is split across sources.

One solution to this is to prefer storing in ENB whenever it's needed, and store the rest (as said, sometimes parts of an entity) in our database. Then, whenever a type is needed, we assemble it by querying both our own database as well as calling ENB through API (we don't have direct access to ENB's database).

Another solution is to simply duplicate the data. This instinctively feels bad because we have to update two sources whenever anything is changed, and we have to make sure they stay in sync (what happens if one update fails and the other doesn't?).

What I'm looking for is if any solution is better than the other, and if there is a name for this pattern of splitting a schema across multiple sources i.e. our own and ENB.

Source Link
Jokab
Jokab
  • 141
  • 5

Pattern for schema split across sources

I was not sure how to title this question, but bear with me.

My company is building a new product and for it we will use a third-party service (let's call it ENB for short) to be responsible for many operations on our data that are not our core business. It's in .NET Core if it matters.

To illustrate I will use the entity ApplicationUser, which is the user that logs in to our application. ApplicationUser will consist of account data as well as a Person, representing the real life person that created this account. To function, ENB needs the Person object and most of its data to function, so we have to create the Person object in ENB. This puts us in a situation where if we store the Person in both our database and in ENB, we will have duplicated the data which rings all kinds of alarm bells in my head.

The above is the case for many of our entities: ENB needs their data to function so we have to store it there. For others, part of the fields of a domain object are specific to our application and parts are needed by ENB. This is why I say that the schema is split across sources.

One solution to this is to prefer storing in ENB whenever it's needed, and store the rest (as said, sometimes parts of an entity) in our database. Then, whenever a type is needed, we assemble it by querying both our own database as well as calling ENB through API (we don't have direct access to ENB's database).

Another solution is to simply duplicate the data. This instinctively feels bad because we have to update two sources whenever anything is changed, and we have to make sure they stay in sync (what happens if one update fails and the other doesn't?).

What I'm looking for is if any solution is better than the other, and if there is a name for this pattern of splitting a schema across multiple sources i.e. our own and ENB.