CODEWITHSUNDEEP
javaooparchitecturedomain-driven-design
Amit Mizrahi
Amit Mizrahi

Reputation: 67

Separate domain models from presention

I have read a lot about DDD and architecture and the past few weeks and I came to a conclusion that my current project is really messed up. the application(web app) shows real-time locations(updates every 2 seconds) of rented cars, their location comes from a legacy code (background service that gets the data from many sources and puts it in the db in a certain format) that can't be changed for now, our application takes the data from the db , convert it to different format - a format that's suitable for our maps infrastructure (currently ESRI) and store it back in the db so that all the users will get the data as quickly as possible.

My problem is our domain models (car, train..) is mixed with presentation implementation, for example our car class looks something like

@Entity
class Car {
  long id; 
  @Ref long manufacturerId
  @Ref String customerId;
  ESRIJson currLocation; (pretension related)

How can I separate my Car model from presentation impl because now we use ESRI, tomorrow we might use something else, However the fact that it is real-time must be considered, because I can't covert between the formats for each request, this is very heavy process.

Upvotes: 1

Views: 117

Answers (1)

Alexey Zimarev
Alexey Zimarev

Reputation: 19600

Take a look at CQRS that explains that you might want to split one object (Car in your case) to two. One is used for writing (this is actually where your domain model lives) and another one is used for reading. The model for the read-side is more optimized for reading and it perfectly OK to have presentation-specific data in your read model. You can even have multiple read models, optimized for different purposes.

In addition, what you are trying to do is "isolating brown", you deal with your legacy system as a separate bounded context. You, reading from that legacy database (I am wondering if you can find a better way to do this), is using some sort of an anti-corruption layer towards your own BC. This is a good and well-known pattern in DDD.

Upvotes: 2

Related Questions