architecture

2018-01-19T19:05:03.000412Z

> This is less an argument for moving constraints to the database, though, and more for not using databases as integration points. Hm. If your not using databases for integration points, then what are you using for integration points?

fellshard 2018-01-19T19:27:11.000510Z

Processes, via facade or domain APIs, though perhaps Datomic / CQRS-based DB designs alleviate the old 'everyone connect to one relational DB' problem.

fellshard 2018-01-19T19:28:36.000212Z

In the end, competing domains end up corrupting one another's' data models if you try and just shove everything into a single relational DB. The more domains you add, the harder it is for them to preserve understanding for all other domains.

2018-01-19T20:52:13.000575Z

I think understand what your suggesting, but i’m not sure how not using a db resolves it. I think what your suggesting is more that we can build more flexible entry points ontop of immutable data. Streaming queries over Immutable kafka logs thorough onyx dont have to worry about stepping on each others toes (no master schema).

fellshard 2018-01-19T21:15:26.000159Z

Precisely. Not saying to not use a relational DB, but rather to scope each relational DB to a single domain. Assuming that new domains can just connect to the database and share it seamlessly with other domains will get you into deep trouble, as relational DBs just aren't flexible enough to allow for independent change. Datomic's datoms are one way you can still centralize your data source without necessarily forcing other apps to integrate. Similarly, abstracting your data as an immutable log provides flexible writes and reads, with lower chance of breakage.