6 ms·

I've seen a lot of different enterprise systems. In my experience it's not the db that's causes this inflexibility issue, but designing the architecture of syst

by joshka 4y ago

I've seen a lot of different enterprise systems. In my experience it's not the db that's causes this inflexibility issue, but designing the architecture of systems data-first (using Data Dictionaries / ER diagrams etc.) rather than use-case-first that leads to this sort of problem. When a data schema is the foundation of a system, it's often the most difficult thing to change.

doctor_eval 4y ago
I don’t know how that works. Your data schema is the foundation of almost any system, regardless of how you generate it. I think this is a common mistake. People think their code is what’s important. But it’s the data and how it gets transformed that is the core of most applications.
- esailija 4y ago
  Data-based architecture means that you have all data about an entity in a single place. Even though if you analyze the domain and all use cases you find that there are slices of that data that never interact together. Example is storing customers address and purchase history in same place, only because they "belong to customer" in a data sense. This is very bad because it leads to entangled architecture where everything depends on everything and you cannot extract truly independent modules. The project implemented like this simply cannot scale beyond a certain size. So no, data is not important but how it is used.
  - doctor_eval 4y ago
    Ok. Perhaps I’m not familiar with this concept of “data-based architecture”. The GP talked about designing around features, which I think is also bad. But maybe they meant more like a DDD approach? So - I certainly agree 100% with what you say about keeping thing independent. Maybe I’m just unfamiliar with the terms.
- jen20 4y ago
  For this to be true (which it is in some contexts), the important question is what the boundary of the "system" is.
  - doctor_eval 4y ago
    I agree. On reflection, I'd also add that I do design systems "data first" however to me this doesn't mean "database first". It's important to think about how data flows through the system, how it gets transformed, and what parts of the system "own" which data. All of this requires understanding of the boundaries of the various systems that make up the whole, which I think is exactly your point.
- joshka 4y ago
  A more specific example is the idea of sitting down and listing all the attributes that define a customer profile (name, addresses, date of birth, etc) and then designing the CRUD around those things. Contrast this to starting with what are the interactions that a customer actually needs to worry about (send me this product to the address in my PayPal* account) *or whatever external system. If you had to make a guess at how many different pieces of information you have about you in databases for services worldwide (and how many of those are inaccurate, or unnecessary to provide the service), that number would be fairly ridiculous for most people (OOM thousands or tens of thousands). Taking the address idea - no e-commerce site really needs to store this as a profile item. It needs to be in my browser so I can autocomplete for any shipping form. The second point I’m making is the same as your last. “How it gets transformed” is often more important to start with than how it is at rest. (I acknowledge in advance this is a weak argument btw).
  - doctor_eval 4y ago
    I actually agree with all of this. Ultimately where I’m coming from is that the flow of data through a system and how it is transformed is actually what’s important. For me that’s taking a “data first” approach, to use your term, but I took the term to mean something different to what you meant. You are totally right about things like customer info. If you have an email component then that’s where email addresses live. If you have a fulfilment component then that’s where physical addresses live. 100% agree that they don’t belong together, at least not by default. In fact, I tend to think of entities like customers as just a uuid. The bits and pieces we attach to that uuid depend on the system. But many domain objects should be treated in a very abstract way. I’m not sure this is widely accepted, but it’s where I got to.

by joshka 4y ago

doctor_eval 4y ago

I don’t know how that works. Your data schema is the foundation of almost any system, regardless of how you generate it. I think this is a common mistake. People think their code is what’s important. But it’s the data and how it gets transformed that is the core of most applications.

esailija 4y ago
Data-based architecture means that you have all data about an entity in a single place. Even though if you analyze the domain and all use cases you find that there are slices of that data that never interact together. Example is storing customers address and purchase history in same place, only because they "belong to customer" in a data sense. This is very bad because it leads to entangled architecture where everything depends on everything and you cannot extract truly independent modules. The project implemented like this simply cannot scale beyond a certain size. So no, data is not important but how it is used.
- doctor_eval 4y ago
  Ok. Perhaps I’m not familiar with this concept of “data-based architecture”. The GP talked about designing around features, which I think is also bad. But maybe they meant more like a DDD approach? So - I certainly agree 100% with what you say about keeping thing independent. Maybe I’m just unfamiliar with the terms.
jen20 4y ago
For this to be true (which it is in some contexts), the important question is what the boundary of the "system" is.
- doctor_eval 4y ago
  I agree. On reflection, I'd also add that I do design systems "data first" however to me this doesn't mean "database first". It's important to think about how data flows through the system, how it gets transformed, and what parts of the system "own" which data. All of this requires understanding of the boundaries of the various systems that make up the whole, which I think is exactly your point.
joshka 4y ago
A more specific example is the idea of sitting down and listing all the attributes that define a customer profile (name, addresses, date of birth, etc) and then designing the CRUD around those things. Contrast this to starting with what are the interactions that a customer actually needs to worry about (send me this product to the address in my PayPal* account) *or whatever external system. If you had to make a guess at how many different pieces of information you have about you in databases for services worldwide (and how many of those are inaccurate, or unnecessary to provide the service), that number would be fairly ridiculous for most people (OOM thousands or tens of thousands). Taking the address idea - no e-commerce site really needs to store this as a profile item. It needs to be in my browser so I can autocomplete for any shipping form. The second point I’m making is the same as your last. “How it gets transformed” is often more important to start with than how it is at rest. (I acknowledge in advance this is a weak argument btw).
- doctor_eval 4y ago
  I actually agree with all of this. Ultimately where I’m coming from is that the flow of data through a system and how it is transformed is actually what’s important. For me that’s taking a “data first” approach, to use your term, but I took the term to mean something different to what you meant. You are totally right about things like customer info. If you have an email component then that’s where email addresses live. If you have a fulfilment component then that’s where physical addresses live. 100% agree that they don’t belong together, at least not by default. In fact, I tend to think of entities like customers as just a uuid. The bits and pieces we attach to that uuid depend on the system. But many domain objects should be treated in a very abstract way. I’m not sure this is widely accepted, but it’s where I got to.