Com a evolução dos aplicativos nascem novas técnicas, frameworks, linguagens de programação, porém, existe um fato consolidado dentro da arquitetura de software corporativo que é a integração com alguma tecnologia necessária para armazenar as informações inerentes ao sistema. Seja SQL ou NoSQL um ponto importante é que o paradigma das linguagens difere da tecnologia do banco de dados. Com o intuito de facilitar o desenvolvimento surgem as ferramentas que realizam a interpretação entre a camada da aplicação e os bancos. Assim, aparecem grandes desafios: como lidar com essa lacuna multiparadigma? Como favorecer o desenvolvimento sem impactar a performance e a modelagem no banco de dados? O objetivo dessa palestra é falar um pouco desses pontos para que, finalmente, os programadores e os DBAs conseguam viver em paz e harmonia.

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