Design Pressure

https://hynek.me/talks/design-pressure/

Transcript

1. Design Pressure Hynek Schlawack hynek.me
8. The use of ORMs and class- based validation frameworks ruins your projects
9. The use of ORMs and class- based validation frameworks ruins your projects
10. The use of ORMs and class- based validation frameworks ruins your projects unre f lected
11. Not here to take away your toys
12. “Until you make the unconscious conscious, it will direct your life and you will call it fate.” ― C.G. Jung
13. Why do we even write software?
14. Business logic
15. if form.valid(): user = db_session.execute( select(User).where( User.id == form.user_id ) ) if user.something and form.something_else: ruin_life(user) db_session.commit()
16. Design pressure
17. 6769 -420
22. Design pressure: forces that shape your code unintentionally
23. Two pieces of code are coupled if they can only be understood by looking at both
24. ”Controlling complexity is the essence of computer programming.” — Brian W. Kernighan
25. ”Controlling complexity is the essence of computer programming.” — Brian W. Kernighan
26. Testable code is better code
27. The Rising Sea
28. [T] [Q] [S] [R] [M] [L] [V] [G] [D] [V] [V] [Q] [N] [C] [H] [T] [S] [C] [V] [D] [Z] [Q] [J] [D] [M] [Z] [C] [M] [F] [N] [B] [H] [N] [B] [W] [N] [J] [M] [P] [G] [R] [Z] [Z] [C] [Z] [G] [P] [B] [W] [N] [P] [D] [V] [G] [L] [T] ----------------------------------- 1 2 3 4 5 6 7 8 9 Harbor
29. [T] [Q] [S] [R] [M] [L] [V] [G] [D] [V] [V] [Q] [N] [C] [H] [T] [S] [C] [V] [D] [Z] [Q] [J] [D] [M] [Z] [C] [M] [F] [N] [B] [H] [N] [B] [W] [N] [J] [M] [P] [G] [R] [Z] [Z] [C] [Z] [G] [P] [B] [W] [N] [P] [D] [V] [G] [L] [T] ----------------------------------- 1 2 3 4 5 6 7 8 9 Harbor
30. [T] [Q] [S] [R] [M] [L] [V] [G] [D] [V] [V] [Q] [N] [C] [H] [T] [S] [C] [V] [D] [Z] [Q] [J] [D] [M] [Z] [C] [M] [F] [N] [B] [H] [N] [B] [W] [N] [J] [M] [P] [G] [R] [Z] [Z] [C] [Z] [G] [P] [B] [W] [N] [P] [D] [V] [G] [L] [T] ----------------------------------- 1 2 3 4 5 6 7 8 9 Harbor
31. [T] [Q] [S] [R] [M] [L] [V] [G] [D] [V] [V] [Q] [N] [C] [H] [T] [S] [C] [V] [D] [Z] [Q] [J] [D] [M] [Z] [C] [M] [F] [N] [B] [H] [N] [B] [W] [N] [J] [M] [P] [G] [R] [Z] [Z] [C] [Z] [G] [P] [B] [W] [N] [P] [D] [V] [G] [L] [T] ----------------------------------- 1 2 3 4 5 6 7 8 9 Harbor move 5 from 4 to 9 move 3 from 5 to 1 move 12 from 9 to 6 ... Instructions
32. [T] [Q] [S] [R] [M] [L] [V] [G] [D] [V] [V] [Q] [N] [C] [H] [T] [S] [C] [V] [D] [Z] [Q] [J] [D] [M] [Z] [C] [M] [F] [N] [B] [H] [N] [B] [W] [N] [J] [M] [P] [G] [R] [Z] [Z] [C] [Z] [G] [P] [B] [W] [N] [P] [D] [V] [G] [L] [T] ----------------------------------- 1 2 3 4 5 6 7 8 9 Harbor move 5 from 4 to 9 move 3 from 5 to 1 move 12 from 9 to 6 ... Instructions
33. [T] [Q] [S] [R] [M] [L] [V] [G] [D] [V] [V] [Q] [N] [C] [H] [T] [S] [C] [V] [D] [Z] [Q] [J] [D] [M] [Z] [C] [M] [F] [N] [B] [H] [N] [B] [W] [N] [J] [M] [P] [G] [R] [Z] [Z] [C] [Z] [G] [P] [B] [W] [N] [P] [D] [V] [G] [L] [T] ----------------------------------- 1 2 3 4 5 6 7 8 9 Harbor move 5 from 4 to 9 move 3 from 5 to 1 move 12 from 9 to 6 ... Instructions “You should structure your data so that the problem solves itself.”
34. @dataclass class Instruction: source: int destination: int count: int
35. @dataclass class Instruction: source: int destination: int count: int @dataclass class Harbor: stacks: List[Stack] def execute(self, i: Instruction): source = self.stacks[i.source] destination = self.stacks[i.destination] payload = source.popsome(i.count) destination.extend(payload)
36. @dataclass class Instruction: source: int destination: int count: int @dataclass class Harbor: stacks: List[Stack] def execute(self, i: Instruction): source = self.stacks[i.source] destination = self.stacks[i.destination] payload = source.popsome(i.count) destination.extend(payload)
37. @dataclass class Instruction: source: int destination: int count: int @dataclass class Harbor: stacks: List[Stack] def execute(self, i: Instruction): source = self.stacks[i.source] destination = self.stacks[i.destination] payload = source.popsome(i.count) destination.extend(payload)
38. @dataclass class Instruction: source: int destination: int count: int @dataclass class Harbor: stacks: List[Stack] def execute(self, i: Instruction): source = self.stacks[i.source] destination = self.stacks[i.destination] payload = source.popsome(i.count) destination.extend(payload) @dataclass class Stack: boxes: List[Box] def popsome(self, count: int) -> List[Box]: tail = self.boxes[-count:] self.boxes = self.boxes[:-count] return tail def extend(self, some: List[Box]): self.boxes.extend(some)
39. @dataclass class Instruction: source: int destination: int count: int @dataclass class Harbor: stacks: List[Stack] def execute(self, i: Instruction): source = self.stacks[i.source] destination = self.stacks[i.destination] payload = source.popsome(i.count) destination.extend(payload) @dataclass class Stack: boxes: List[Box] def popsome(self, count: int) -> List[Box]: tail = self.boxes[-count:] self.boxes = self.boxes[:-count] return tail def extend(self, some: List[Box]): self.boxes.extend(some)
40. @dataclass class Instruction: source: int destination: int count: int @dataclass class Harbor: stacks: List[Stack] def execute(self, i: Instruction): source = self.stacks[i.source] destination = self.stacks[i.destination] payload = source.popsome(i.count) destination.extend(payload) @dataclass class Stack: boxes: List[Box] def popsome(self, count: int) -> List[Box]: tail = self.boxes[-count:] self.boxes = self.boxes[:-count] return tail def extend(self, some: List[Box]): self.boxes.extend(some)
41. @dataclass class Instruction: source: int destination: int count: int @dataclass class Harbor: stacks: List[Stack] def execute(self, i: Instruction): source = self.stacks[i.source] destination = self.stacks[i.destination] payload = source.popsome(i.count) destination.extend(payload) @dataclass class Stack: boxes: List[Box] def popsome(self, count: int) -> List[Box]: tail = self.boxes[-count:] self.boxes = self.boxes[:-count] return tail def extend(self, some: List[Box]): self.boxes.extend(some)
42. “In software engineering, a domain model is a conceptual model of the domain that incorporates both behavior and data.” — Wikipedia Domain Model
43. Domain knowledge distilled into code
44. @dataclass class Instruction: source: int destination: int count: int @dataclass class Harbor: stacks: List[Stack] def execute(self, i: Instruction): source = self.stacks[i.source] destination = self.stacks[i.destination] payload = source.popsome(i.count) destination.extend(payload) class Stack: boxes: List[Box] def popsome(self, count: int) -> List[Box]: tail = self.boxes[-count:] self.boxes = self.boxes[:-count] return tail def extend(self, some: List[Box]): self.boxes.extend(some)
45. @dataclass class Instruction: source: int destination: int count: int @dataclass class Harbor: stacks: List[Stack] def execute(self, i: Instruction): source = self.stacks[i.source] destination = self.stacks[i.destination] payload = source.popsome(i.count) destination.extend(payload) class Stack: boxes: List[Box] def popsome(self, count: int) -> List[Box]: tail = self.boxes[-count:] self.boxes = self.boxes[:-count] return tail def extend(self, some: List[Box]): self.boxes.extend(some)
46. The Darkness def parse_harbor(stackstr: Iterable[str]) -> Harbor: bottomup = list(stackitr)[:-1] harbor: Harbor = Harbor([[] for _ in range(N_STACKS)]) for line in bottomup: tokens = [ ''.join(x for _, x in g[1]) for g in groupby( enumerate(line), lambda t: t[0] // N_CHARS_IN_BOX_TOKEN ) ] boxes: List[Box] = [t.strip('[] ') for t in tokens] for box, stack in zip(boxes, harbor.iter_stacks()): if box: stack.append(box) return harbor
47. “The shitty stu ff should happen on the outside layer of your program, that interacts with the "outside world". Once it's inside, organize it into nice data structures so that operations (i.e. code) are as self-evident as possible.” — Matthew Drury
48. The shape of the data determines the shape of the code
49. Problem #1 best model for web apis ≠ best model for business logic ≠ best model for databases
50. Con f licting goals Web API what is best for the user? what is a good standard? (e.g., JSON:API)
51. Con f licting goals Web API what is best for the user? what is a good standard? (e.g., JSON:API) Database schema how to store data e ff ectively? how to normalize? → storage vs performance
52. Con f licting goals Web API what is best for the user? what is a good standard? (e.g., JSON:API) Database schema how to store data e ff ectively? how to normalize? → storage vs performance Domain model how to solve business requirement?
53. Con f licting goals Web API what is best for the user? what is a good standard? (e.g., JSON:API) Database schema how to store data e ff ectively? how to normalize? → storage vs performance Domain model how to solve business requirement?
54. Con f licting goals Web API what is best for the user? what is a good standard? (e.g., JSON:API) Database schema how to store data e ff ectively? how to normalize? → storage vs performance Domain model how to solve business requirement?
57. type CustomerID = UUID
58. type CustomerID = UUID class OpenInvoice: customer: CustomerID amount: Decimal due_on: date
59. type CustomerID = UUID class OpenInvoice: customer: CustomerID amount: Decimal due_on: date class PaidInvoice: customer: CustomerID amount: Decimal paid_on: date
60. type CustomerID = UUID class OpenInvoice: customer: CustomerID amount: Decimal due_on: date class PaidInvoice: customer: CustomerID amount: Decimal paid_on: date class OverdueInvoice: customer: CustomerID amount: Decimal overdue_by: int reminder_level: int
61. type CustomerID = UUID class OpenInvoice: customer: CustomerID amount: Decimal due_on: date class PaidInvoice: customer: CustomerID amount: Decimal paid_on: date def release_the_hounds( invs: list[OverdueInvoice] ) -> list[CustomerID]: ... class OverdueInvoice: customer: CustomerID amount: Decimal overdue_by: int reminder_level: int
62. class Invoice: customer: CustomerID amount: Decimal due_on: date paid_on: date | None overdue_by: int | None reminder_level: int | None
63. Approach 1 (bad) ORM xor Web = primary
64. Approach 1 (bad) ORM xor Web = primary database-driven “design”
65. Approach 2 (worse)
66. Approach 2 (worse)
67. Approach 2 (worse) domain model 🥺 pressure pressure
68. Problem #2 Both calcify (eventually)
69. Problem #2 Both calcify (eventually)
70. You have lost control over your domain model and therefore over your business logic
71. — Adam Montgomery
72. ”It's ok to have duplicative-looking types for di ff erent layers of a project—e.g. ORM, API schema, and business logic. Types need to be easy to change and reason about so we can adapt them to our evolving requirements. — Adam Montgomery
73. ”It's ok to have duplicative-looking types for di ff Types near the edge (like API schemas and database tables) are inherently less f lexible. It's often better to explicitly map types between these layers rather than create a "franken-type" and allow the least f lexible layer to calcify the rest.” — Adam Montgomery
74. ”good examples are by far the hardest part of explaining design” — Kent Beck
77. class PostalAddress: addr1: str | None addr2: str | None zip: str | None state: str | None city: str | None country: str
78. class USAddress: addr1: str addr2: str | None zip: str state: str city: str country: str
79. def format_us_address( addr1: str, addr2: str | None, zip: str, state: str, city: str, country: str, ) -> str: ...
80. Start with the domain model
81. Start with the domain model
82. Start with the domain model then start ~engineering~ It depends, but
83. Know thy domain
84. Know thy tools Know thy domain
87. Not here to take away your toys¹
88. Not here to take away your toys¹ ¹ But they might be attractive nuisances
89. “To me, complexity is not about how many keys I have to press – it’s about how di ff icult it is to reason about the consequences of what I’m doing.” — Hynek, a famous YouTuber We’re too lazy
90. “To me, complexity is not about how many keys I have to press – it’s about how di ff icult it is to reason about the consequences of what I’m doing.” — Hynek, a famous YouTuber We’re too lazy
91. “To me, complexity is not about how many keys I have to press – it’s about how di ff icult it is to reason about the consequences of what I’m doing.” — Hynek, a famous YouTuber We’re too lazy
96. Takeaways
97. Takeaways 1. your business code is sacred
98. Takeaways 1. your business code is sacred 2. protect it from your tools
99. Takeaways 1. your business code is sacred 2. protect it from your tools 3. engineering matters
101. OX.CX/DESIGN
102. OX.CX/DESIGN VRMD.DE
103. OX.CX/DESIGN VRMD.DE HYNEK.ME
104. OX.CX/DESIGN VRMD.DE HYNEK.ME YOUTUBE.COM/ @THE_HYNEK