❓ Help Deleted

[Falln]

Case close

 

[pixkit]

Just copy the same illustration. Replace the text on the Master file with RDBMS. And you're done.

The requirement is to use the same model. Ok we got that.

The requirement is to draw it. Ok we got that. What's wrong with my suggested solution?

As a side note, looking at the original diagram, even though the problem states this is traditional approach, it looks like it's a modern approach. It reminds me of how microservices should be designed with a clear bounded context. Each context is a microservice and has its own database (here it's file system, but the storage type should be secondary concern).

To access the data from another system, communication is done through APIs and not a shared database. Your prof might be thinking of one monolithic database which I don't recommend.

 

[dee-u]

The Order Filing System and Invoicing System could just be using the same database and could just use one Customer table, do you advise that they should be using different databases?

 

[pixkit]

It depends on the constraints of the business. The constraints will dictate your achitecture. The modern approach though is to use microservices. Each microservice has a clear bounded context with clear seaparation from top to bottom. Separate teams that control frontend to db. So the answer to your question is yes. But if the constraints of the business is every data is the same and they can only pay you 10Php, yeah I'll just stick everything on one db and do whatever.

 

[dee-u]

[XX='pixkit, c: 253900, m: 1446869'][/XX] May I ask how would cascading updates/deletes work for multiple database having the same set of data (Customer) table?

 

[dee-u]

TS, dapat iisa lang yung Customer table nung Order Filing at Invoicing System.

 

[0xLouis]

I think sinabi sa image na duplicate data yung customer file, so baka gawin mo lang isa yung customer (table) then yung arrow ng two systems nag-popoint sa iisang customer table

 

[pixkit]

dee-u, Cascading updates and deletes with microservices isn't something you would do when doing DDD with a clear bounded context. Same customer, same data, same bounded context, same business function -- that belongs to one microservice. A single microservice can implement the traditional cascades since it has total control of its own db. But cross cascades with other microservices do not. You will have to implement some form of synchronization like the saga pattern.