3 ms·

For me, this is a "near miss" in that the data model is an implementation detail. Instead, the subtitle identifies where the value resides: Your product's c

For me, this is a "near miss" in that the data model is an implementation detail. Instead, the subtitle identifies where the value resides: Your product's core abstractions determine whether new features compound into a moat or just add to a feature list. Which is captured by the Domain Model[0]. How it is managed in a persistent store is where a data model comes into play. See also Domain Driven Design[1]. 0 - https://en.wikipedia.org/wiki/Domain_model https://en.wikipedia.org/wiki/Domain_model 1 - https://en.wikipedia.org/wiki/Domain-driven_design https://en.wikipedia.org/wiki/Domain-driven_design

android521 1y ago
there is a subtle difference, it is not just domain driven desgin. It is basically trying to innovate a new way to think about in an existing domain (eg docs vs blocks in note taking). ~ "Your data model is your destiny. The paradox is that this choice happens when you know the least about your market, but that’s also why it’s so powerful when you get it right. Competitors who’ve already built on different foundations can’t simply copy your insight. They’d have to start over, and by then, you’ve compounded your advantage.".
- bonesss 1y ago
  You’re describing core features of Domain Driven Design. Innovating, evolving, creating, and capturing new domain concepts to create Blue Ocean solutions inside and outside the Enterprise. Iterating on core concepts, via subject matter expert led/involved discussions and designs, and using new concepts to better articulate the domain. Managing that change over time and accounting for ontological and taxonomical overlap versus Enterprise System development needs. That’s the foundation that can actively copy insights, and doesn’t rely on Immaculate Specification or premature data modelling. No need to start over, thanks to clearly separated concerns. Note: copying an insight is a far cry from having the wherewithal to make that insight, there are numerous downstream benefits to articulating your business domain clearly and early.
- AdieuToLogic 1y ago
  "Data model" is a software engineering term of art[0] which identifies artifacts specific to managing the persistent representation of information relevant to a system's operation. This representation is often a different, simplified, version of what a system uses internally to define and provide its value. > It is basically trying to innovate a new way to think about in an existing domain ... Note that a domain is not the same as a domain model. > "Your data model is your destiny." This is why I consider the article a "near miss." If the above quote from the post was instead "your domain model is your destiny", the subsequent quoted statements not only would need no alteration but would substantiate the topic at hand being domain modeling and the organizational value found therein. 0 - https://www.merriam-webster.com/dictionary/term%20of%20art https://www.merriam-webster.com/dictionary/term%20of%20art
lysecret 1y ago
I agree was about to comment that this article fits a domain model more than a data model.

android521 1y ago

there is a subtle difference, it is not just domain driven desgin. It is basically trying to innovate a new way to think about in an existing domain (eg docs vs blocks in note taking). ~ "Your data model is your destiny. The paradox is that this choice happens when you know the least about your market, but that’s also why it’s so powerful when you get it right. Competitors who’ve already built on different foundations can’t simply copy your insight. They’d have to start over, and by then, you’ve compounded your advantage.".

bonesss 1y ago
You’re describing core features of Domain Driven Design. Innovating, evolving, creating, and capturing new domain concepts to create Blue Ocean solutions inside and outside the Enterprise. Iterating on core concepts, via subject matter expert led/involved discussions and designs, and using new concepts to better articulate the domain. Managing that change over time and accounting for ontological and taxonomical overlap versus Enterprise System development needs. That’s the foundation that can actively copy insights, and doesn’t rely on Immaculate Specification or premature data modelling. No need to start over, thanks to clearly separated concerns. Note: copying an insight is a far cry from having the wherewithal to make that insight, there are numerous downstream benefits to articulating your business domain clearly and early.
AdieuToLogic 1y ago
"Data model" is a software engineering term of art[0] which identifies artifacts specific to managing the persistent representation of information relevant to a system's operation. This representation is often a different, simplified, version of what a system uses internally to define and provide its value. > It is basically trying to innovate a new way to think about in an existing domain ... Note that a domain is not the same as a domain model. > "Your data model is your destiny." This is why I consider the article a "near miss." If the above quote from the post was instead "your domain model is your destiny", the subsequent quoted statements not only would need no alteration but would substantiate the topic at hand being domain modeling and the organizational value found therein. 0 - https://www.merriam-webster.com/dictionary/term%20of%20art https://www.merriam-webster.com/dictionary/term%20of%20art

lysecret 1y ago

I agree was about to comment that this article fits a domain model more than a data model.