Question

at first We have a model like

class Person extends EntityBase<Person, PersonNumber>{
 private PersonNumber personNumber;
 private String name;
 private Contact contact;
 private String educationLevel;
}
class Contact extends ValueObjectBase<Contact> {
  private String phone;
  private String address;
  private String contactPerson;
}

but now we have to integration with anther system name “System DC”, the original person table been take apart, the personNumber,name, phone,address column now moved to “System DC” . And “SystemDC” provide a database view “DC_PersonView” to us for query.If we need to create a person we have to do call webservice from “SystemDC”.

so we define a personDTO like

 class PersonDTO{
 private PersonNumber personNumber;
 private String name;
 private String phone;
 private String address;
 }

plan 1:

1. refactor person to IPerson interface

2. define a PersonWrape Class

   class PersonWrape implements IPerson {
    private Person person;
    private PersonDTO personDTO;
   }
   

3. in PersonWrape repository

   void SavePerson(IPerson person) {
     systemDC.saveWebservice(person.getPersonDTO);
     personRepository.save(person);// map the column not in systemDC like  educationLevel to our person table.
     }
   

plan 2:
only modify the personRepository:

    void SavePerson(IPerson person) {
      PersonDTO personDTO = PersonDTO.fromEntiry(person);
      systemDC.saveWebservice(personDTO);
      personRepository.save(person);// map the column not in systemDC like  educationLevel
      }

but query person will be truble..

How do we model under this situation? please give us some suggestions.

Answer 1

It seems like you have an integration scenario between two bounded contexts (BC). In these scenarios, it is often possible to discern a relationship BCs that can determine how entity changes are propagated.

In your use case is appears that you have a single notion of a person (each person has a single identity shared among BCs), but you have 2 different BCs where a person is manifest with each BC containing and managing different person data. Then the save operation that you discuss is actually two save operations, one in each BC. Each BC saves information that it is interested in. If you have a use case, such as a UI form that accepts person information for both BCs, that use case should send the save command to both BCs explicitly. Your plan 2 is closest to this approach, however I would not place that code in the repository. Instead, I would call two distinct services directly from the presentation layer or the application layer.

What you can also consider is whether there is some sort of downstream relationship between your original BC (let’s call it A) and System DC. For instance, if DC is downstream from A for person data, then instead of calling both services explicitly during a save, you can implement an event-driven approach. With this approach, A would publish events regarding changes to person data and an integration point between A and DC would subscribe to those events and make the appropriate modifications in DC. Note that this approach is usually eventually consistent. Overall, the event-driven approach is more complicated but also more flexible.