5 ms·
1. Polymorphism 2. Vendors are often pushing bad architecture 3. Architects often push things for the wrong reasons 4. Companies often push risk to their ven
by ChicagoDave 6y ago
1. Polymorphism
2. Vendors are often pushing bad architecture
3. Architects often push things for the wrong reasons
4. Companies often push risk to their vendors, avoiding
collaboration, inherently increasing risk
5. ORM's hide business logic, preventing a company from understanding its business and adapting to change
6. Relational Databases are an operational anti-pattern
7. Graph databases are excellent tools for common problems like security, social media
8. Document databases are excellent tools for Event Stores and CQRS
9. Cloud native development (FaaS) is awesome
10. Domain-Driven Design and Event Storming are excellent disciplines to add to a corporate development group
11. Corporations inherently don't understand Agile because they have to measure everything through strong process definition
- etripe 6y agoHow exactly do ORMs hide business logic?
- ChicagoDave 6y agoI've seen implementations of ORM's where the complicated joins of relational operations are embedded in the ORM definition. It's done for performance, without considering the impact on future business process review. This inherently hides that logic from external review. One of the things we need to enable as architects is to make sure the systems we build are adaptable. Any "framework" that begins to hide logic through efficiencies is bad architecture.
- attil-io 6y ago> 6. Relational Databases are an operational anti-pattern Could you please expand on this? What is wrong with Relational Databases and what would be the "correct" pattern?
- ChicagoDave 6y agoThe keyword in my statement is _operational_. Relational databases are excellent for analytics and reporting. But in an operational system with well-defined boundaries, it's more than likely that only portions of the larger system are required for any transactional behavior. In a modern architecture, you could simply write all transactions to an event store (write only) and use CQRS and a relational cache store for reads. Another aspect of all of this is the misconception that we should design systems based on a relational data model. This only leads you through the whole impedance mismatch of ORM's and how you serialize/deserialize your bounded contexts or objects. We should not do this at all. We should design systems on those bound contexts and determine the data store accordingly. Operationally, a Document Database or Event Store is going to be the best tool. We can fire change events at a data warehouse to store data in a relational manner for analytics and reporting, but none of that is necessary for our operational system. In your operational system, if you need any sort of complex join, you've already created a poor design. I will say this. This did not occur to me until I'd gone through the process of developing a complex system using Domain-Driven Design. Until you've done that, the old patterns will remain like concrete.
- zamubafoo 6y agoIf I'm reading this correctly, then it's not relational databases/relational data models that are the problem, but instead the normalization across bounded contexts within a problem domain?
- ChicagoDave 6y agoPartly yes. But it’s also the realization that we tend to start with an ERD or domain model before even looking at boundaries. We’re product-oriented. And vendors don’t help. Look at how hard everyone is pushing containers. Containers have uses, but there’s no rational explanation for the effort behind their marketing push. Simpler is better. Boundaries need to be respected. Tools should be selected based on need, not desire.
- jiriro 6y agoCould you please elaborate/navigate to some theory/resources? What is Domain-Driven Design? What are the “bound contexts”?
- ChicagoDave 6y agoGoogle it. Eric Evans wrote a book 15 years ago. It’s kind of a big deal.