In the information age, with new technologies, frameworks, and programming languages, there is an aspect of technology that never changes. All applications need a storage integration related to their system; either SQL or NoSQL, to point out that there is a different paradigm among the development team and the database team. To make developer life easier, new frameworks emerged that convert between the application layer and the database, which includes the famous ORM. Indeed, contemporary challenges appear such as how to handle different paradigms that are in software development and how to make a regular development without impacting on the database.

1. Otávio Santana
@otaviojava
ORMs heroes or villains indoors the
data architecture?

2. Architecture vs Design
● Flexibility
● Scalability
● Reusability
● Module is doing
● The classes scope
● The functions purposes

3. Architecture
● Serverless Architecture
● Event-Driven
Architecture
● Microservices
Architecture

4. Design
● Single Responsibility
Principle
● Open Closed Principle
● Liskov substitution
principle
● Interface Segregation
Principle
● Dependency Inversion
Principle
● Design Patterns

5. Divide and Conquer

6. Modules
● Hardware History
● Testability
● Mock

7. Layer vs Tier

8. Layers
Data Access Layer
DAO
API

9. Paradigms
● Objects
● Functional
● Reactive
● Relational
● Key-value
● Column-Family
● Document
● Graph

10. Conversion

11. Mapper
Real entities
Less Database
Less boilerplate
More domain visibility in
your system

12. Mapper
Real entities are not database structure
Less Database means bad database
design
Less boilerplate is not magic
Domain is not Database

13. Active Record
● Simple
● Easy to learn
public class Person extends Model {}
Person person = new Person("Ada","Lovelace");
person.saveIt();
Person ada = Person.findFirst("name = ?", "Ada");
String name = ada.get("name");
ada.delete();
List<Person> people = Person.where("name = 'Ada'");

14. Active Record
● Database Coupling
● Performance
bottlenecks
● Transactions?
● Connections?
● Pool?

15. Mapper
@Entity
public class Person {
private @Id String name;
private @Column String lastName;
}
EntityManager manager = getEntityManager();
manager.getTransaction().begin();
Person person = new Person("Ada","Lovelace");
manager.persist(person);
manager.getTransaction().commit();
List<Person> people = manager.createQuery("SELECT p from Person where
p.name = @name").setParameter("name", "Ada").getResultList();
● Flexibility
● Performant

16. Mapper
● Hard
● Setup

17. Object-relational impedance mismatch
● Encapsulation
● Accessibility
● Interface, class, inheritance and polymorphism
● Data type differences

18. Model
● Database normalization
● Database denormalization

19. Keys
The AUTOINCREMENT keyword imposes extra CPU, memory, disk space, and disk I/O overhead and
should be avoided if not strictly needed. It is usually not needed.
● Performance
● Security
● Compound key
● UUID?

20. Performance issues
● Indexes
● N+1 Query
● Search Engine

21. Cache

22. Security
Hard coding
Plain password
One user

23. Schemaless
● Data integrity
● Security
● Validation

24. Rich Model
● Smart Domain Objects
● Thin Services
● Encapsulate
● No Procedural code

25. Designing
Bulletproof Code
● Hide data
● Expose behavior
● Don't memorize
● Consistency in the Model

26. Designing Bulletproof Code
● Builder
● Fluent API
● DSL
● Factory Method
● When Make a Type

27. Clean
Architecture
● Split what matter
● Domain Layer does NOT
depend on Data Layer.
● Agnostic

28. Database Adapter
Layer

29. Silver Bullet

30. Summary
● Impact
● Volumetry
● Active Record vs Object
Mapper
● Design outside the code
● Know-how vs Know-why
● Index
● Model to Data
● Trade-offs
● DBA is not your enemy

31. Thank you
Otavio Santana
@otaviojava