3 ms·

Services should be communicating through public interfaces, not databases. Otherwise you're confusing implementation details with public interfaces and change b

Services should be communicating through public interfaces, not databases. Otherwise you're confusing implementation details with public interfaces and change becomes really hard and risky. I can see this being useful in some legacy system that you have to maintain that is not changing anymore, but otherwise I don't see a good use for it for properly designed and new projects.

kadenshep 8y ago
>but otherwise I don't see a good use for it for properly designed and new projects. What's your definition of properly designed projects?
- imbusy111 8y ago
  A project that adapts easily to changing business requirements and environments.
  - namibj 8y ago
    There are cases where you do know that those don't change as fast or that the actual core of your software needs a fundamental rewrite anyway to pivot. Think about number crunching or comparable small software.
  - kadenshep 8y ago
    I don't see anything that doesn't meet those requirements.
jobinau 8y ago
Suppose we want to run a complex reporting query on tables in Sales database (running MySQL) and Finance database (running PostgreSQL). What is the good option without duplicating data from one system to another?
- gav 8y ago
  Duplicating data isn't a bad thing. Having a process that copies data into a reporting system solves the problem that otherwise it would be brittle (changes to either system might break things) and performance (any reporting queries affect realtime ones). Also, as it's decoupled, pulling in data from a 3rd system, e.g. CRM is possible.
- logophobia 8y ago
  ETL, that way you can also ensure your data gets put in a format that'd make it easy to report on. Granted, it's not quite as quick as this, and not suited for "one-off" reporting, but it's a lot more flexible. Put things in a nice star schema and you have a good way to do analytics on your data.

kadenshep 8y ago

>but otherwise I don't see a good use for it for properly designed and new projects. What's your definition of properly designed projects?

imbusy111 8y ago
A project that adapts easily to changing business requirements and environments.
- namibj 8y ago
  There are cases where you do know that those don't change as fast or that the actual core of your software needs a fundamental rewrite anyway to pivot. Think about number crunching or comparable small software.
- kadenshep 8y ago
  I don't see anything that doesn't meet those requirements.

jobinau 8y ago

Suppose we want to run a complex reporting query on tables in Sales database (running MySQL) and Finance database (running PostgreSQL). What is the good option without duplicating data from one system to another?

gav 8y ago
Duplicating data isn't a bad thing. Having a process that copies data into a reporting system solves the problem that otherwise it would be brittle (changes to either system might break things) and performance (any reporting queries affect realtime ones). Also, as it's decoupled, pulling in data from a 3rd system, e.g. CRM is possible.
logophobia 8y ago
ETL, that way you can also ensure your data gets put in a format that'd make it easy to report on. Granted, it's not quite as quick as this, and not suited for "one-off" reporting, but it's a lot more flexible. Put things in a nice star schema and you have a good way to do analytics on your data.