19. causal-loop diagram(CLD) stock and ow diagram(SFD)
20.
21. Uncle Bob Chapter 3 to 6: Structured programming
Object-oriented programming Functional programming
22. Chapter 3 to 6: Structured programming is discipline
imposed upon direct transfer of control. Object-oriented
programming is discipline imposed upon indirect transfer of
control. Functional programming is discipline imposed upon variable
assignment. Each of these three paradigms has taken something away
from us. Each restricts some aspect of the way we write code. None
of them has added to our power or our capabilities.What we have
learned over the last half-century iswhat not to do.
23. Chapter 3 to 6: Structured programming is discipline
imposed upon direct transfer of control. Object-oriented
programming is discipline imposed upon indirect transfer of
control. Functional programming is discipline imposed upon variable
assignment. Each of these three paradigms has taken something away
from us. Each restricts some aspect of the way we write code. None
of them has added to our power or our capabilities.What we have
learned over the last half-century iswhat not to do.
24. Structured programming allows modules to be recursively
decomposed into provable units [] using the restricted control
structures. Structured programming is discipline imposed upon
direct transfer of control.
25. Actions to restrict control structures Structured
programming is discipline imposed upon direct transfer of control.
Actions to decompose modules Complexity of a single programming
unit Eort needed to prove the correctness of a programs
26. Actions to restrict control structures Structured
programming is discipline imposed upon direct transfer of control.
Actions to decompose modules Complexity of a single programming
unit Eort needed to prove the correctness of a program
27. CLD
28. Actions to restrict control structures Structured
programming is discipline imposed upon direct transfer of control.
Actions to decompose modules Eort needed to prove the correctness
of a program Same +
29. http://bit.ly/2gxQFSA
30. Actions to restrict control structures Structured
programming is discipline imposed upon direct transfer of control.
Actions to decompose modules Complexity of a single programming
unit Opposite -
31. http://bit.ly/2yXLVNk
32. Actions to restrict control structures Structured
programming is discipline imposed upon direct transfer of control.
Actions to decompose modules Complexity of a single programming
unit Eort needed to prove the correctness of a program Same +
Opposite -
33. Actions to restrict control structures Structured
programming is discipline imposed upon direct transfer of control.
Actions to decompose modules Complexity of a single programming
unit Eort needed to prove the correctness of a program (Balancing
loop)
34. http://bit.ly/2l4hjUx
35. Reluctance to tackle the problem Eort needed to improve
engineering quality of programs Complexity of a single programming
unit What if reluctant? (Reinforcing loop) or
36. http://bit.ly/2zpyuCb
37. Actions to restrict control structures Actions to decompose
modules Complexity of a single programming unit Eort needed to
prove the correctness of a program Reluctance to tackle the
problem
38. Actions to restrict control structures Actions to decompose
modules Complexity of a single programming unit Reluctance to
tackle the problem #2 #1 ?System Dynamics Eort needed to prove the
correctness of a program
39. http://bit.ly/2zFox4i
40. (dynamic complexity) (detail complexity)
41. Chapter 3 to 6: Structured programming is discipline
imposed upon direct transfer of control. Object-oriented
programming is discipline imposed upon indirect transfer of
control. Functional programming is discipline imposed upon variable
assignment. Each of these three paradigms has taken something away
from us. Each restricts some aspect of the way we write code. None
of them has added to our power or our capabilities.What we have
learned over the last half-century iswhat not to do.
42. Structured programming allows modules to be recursively
decomposed into provable units [] using the restricted control
structures.Building on this foundation, disciplines such as
structured analysis and structured design became popular in the
late 1970s and throughout the 1980s. Structured programming is
discipline imposed upon direct transfer of control.
43. OO is the ability, through the use of polymorphism, to gain
absolute control over every source code dependency in the system.It
allows the architect to create a plugin architecture, in which
modules that contain high-level policies are independent of modules
that contain low-level details. Object-oriented programming is
discipline imposed upon indirect transfer of control.
44. Well-structured applications will be segregated into those
components that do not mutate variables and those that do.If we
have enough storage and enough processor power, we can make our
applications entirely immutableand, therefore, entirely functional.
Functional programming is discipline imposed upon variable
assignment.
45. Complexity of a single programming unit Eort needed to
improve engineering quality of programs Actions to impose
restriction Each restricts some aspect of the way we write code.
Spaghetti Dependency Race condition Structured programming OOP
FP
46. Complexity of a single programming unit Eort needed to
improve engineering quality of programs Actions to impose
restriction
47. Dev velocity Need for improving architecture Size of a
single service instance Stability # services Need for proper
coordination Actions to split services Actions to enhance
anti-fragility Desire to take fundamental solutions Operation
complexity Actions to merge services Near- sightedness
54. Hardware Communication App platform Microservices
Domain-driven design DevOps:Jenkins, GitLab, ELK, Prometheus
Service infra:ZooKeeper, etcd, Consul, Kafka Server infra:Ansible,
Docker, Kubernetes, Mesos, OpenStack, db Microservice ecosystem:
4-layer model
55. model around business concepts adopt a culture of
automation hide internal implementation details decentralize all
the things deploy independently isolate failure highly observable
Domain-driven design CI/CD: Jenkins, GitLab, Docker ecosystem
API-rst design: RAML, Swagger, GraphQL DevOps: Ansible, Docker,
Kubernetes Async choreography: ZooKeeper, etcd, Kafka
Anti-fragility: Akka, Netix OSS Monitoring: Prometheus, ELK
56. One Piece
57. Microservices
58. System Dynamics Model of Microservices Adoption
59. microservices #2 #1 ?System Dynamics
60. Accidental Adversaries Shifting the Burden
61. Dev velocity Need for improving architecture Size of a
single service instance Stability Actions to increase operations
eciency # services Need for proper coordination Actions to split
services Actions to enhance anti-fragility Desire to take
fundamental solutions # unplanned work Operation complexity Actions
to merge services Near- sightedness Accidental Adversaries Shifting
the Burden
62. Dev velocity Need for improving architecture Size of a
single service instance Stability Actions to increase operations
eciency # services Need for proper coordination Actions to split
services Actions to enhance anti-fragility Desire to take
fundamental solutions # unplanned work Operation complexity Actions
to merge services Near- sightedness Lets Begin!
63. Dev velocity Need for improving architecture Size of a
single service instance Actions to split services
64. Dev velocity Need for improving architecture Size of a
single service instance Stability # services Need for proper
coordination Operation complexity Actions to merge services Actions
to split services
65. Dev velocity Need for improving architecture Size of a
single service instance Stability # services Need for proper
coordination Actions to split services Operation complexity Actions
to merge services
66. Dev velocity Need for improving architecture Size of a
single service instance Stability # services Need for proper
coordination Actions to split services Operation complexity Actions
to merge services
67. Dev velocity Need for improving architecture Size of a
single service instance Stability # services Need for proper
coordination Actions to split services Operation complexity Actions
to merge services
68. Dev velocity Need for improving architecture Size of a
single service instance Stability # services Need for proper
coordination Actions to split services Operation complexity Actions
to merge services or
69. Dev velocity Need for improving architecture Size of a
single service instance Stability # services Need for proper
coordination Actions to split services Operation complexity Actions
to merge services
70. Dev velocity Need for improving architecture Size of a
single service instance Stability # services Need for proper
coordination Actions to split services Operation complexity Actions
to merge services Accidental Adversaries
71. Need for improving architecture Size of a single service
instance # services Need for proper coordination Actions to split
services Operation complexity Actions to merge services Dev
velocity Stability Accidental Adversaries
72. Need for improving architecture Size of a single service
instance # services Need for proper coordination Actions to split
services Operation complexity Actions to merge services Dev Ops
Accidental Adversaries
73. Need for improving architecture Size of a single service
instance # services Need for proper coordination Actions to split
services Operation complexity Actions to merge services Coding
Testing Accidental Adversaries
74. Need for improving architecture Size of a single service
instance # services Need for proper coordination Actions to split
services Operation complexity Actions to merge services Discovery
Delivery Accidental Adversaries
75. Stability # services Need for proper coordination Operation
complexity Actions to merge services
76. Stability # services Need for proper coordination Actions
to enhance anti-fragility Operation complexity Actions to merge
services model around business concepts adopt a culture of
automation hide internal implementation details decentralize all
the things deploy independently isolate failure highly
observable
77. Stability Actions to enhance anti-fragility Actions to
merge services ?Two roads diverged in a wood, and I
78. Stability # services Need for proper coordination Actions
to enhance anti-fragility Desire to take fundamental solutions
Operation complexity Actions to merge services Near-
sightedness
79. Stability Actions to enhance anti-fragility Desire to take
fundamental solutions Actions to merge services Near-
sightedness
80. Stability # services Need for proper coordination Actions
to enhance anti-fragility Desire to take fundamental solutions
Operation complexity Actions to merge services Near-
sightedness
81. # services Need for proper coordination Desire to take
fundamental solutions Operation complexity Actions to merge
services Near- sightedness Stability Actions to enhance
anti-fragility
82. # services Need for proper coordination Desire to take
fundamental solutions Operation complexity Actions to merge
services Near- sightedness Stability Actions to enhance
anti-fragility model around business concepts adopt a culture of
automation hide internal implementation details decentralize all
the things deploy independently isolate failure highly observable
Domain-driven design CI/CD: Jenkins, GitLab, Docker ecosystem
API-rst design: RAML, Swagger DevOps: Ansible, Docker, Kubernetes
Async choreography: ZooKeeper, etcd, Kafka Anti-fragility: Akka,
Netix OSS Monitoring: Prometheus, ELK microsevices
83. Actions to enhance anti-fragility Desire to take
fundamental solutions Near- sightedness Stability # services Need
for proper coordination Operation complexity Actions to merge
services
84. # services Need for proper coordination Operation
complexity Stability Actions to enhance anti-fragility Desire to
take fundamental solutions Actions to merge services Near-
sightedness
85. Stability # services Need for proper coordination Actions
to enhance anti-fragility Desire to take fundamental solutions
Operation complexity Actions to merge services Near-
sightedness
86. Stability # services Need for proper coordination Actions
to enhance anti-fragility Desire to take fundamental solutions
Operation complexity Actions to merge services Near- sightedness
Shifting the Burden
87. Dev velocity Need for improving architecture Size of a
single service instance Stability # services Need for proper
coordination Actions to split services Actions to enhance
anti-fragility Desire to take fundamental solutions Operation
complexity Actions to merge services Near- sightedness
88. Dev velocity Need for improving architecture Size of a
single service instance Stability # services Need for proper
coordination Actions to split services Actions to enhance
anti-fragility Desire to take fundamental solutions Operation
complexity Actions to merge services Near- sightedness Accidental
Adversaries Shifting the Burden
89. Accidental Adversaries Shifting the Burden Limits to Growth
Eroding Goals Escalation Success to Successful Tragedy of the
Commons Fixes that Fail Growth and Underinvestment
90. (archetype)
91. microservices
92. Accidental Adversaries Shifting the Burden
93. Shifting the Burden
94. Accidental Adversaries
95. Dev velocity Need for improving architecture Size of a
single service instance Stability # services Need for proper
coordination Actions to split services Actions to enhance
anti-fragility Desire to take fundamental solutions Operation
complexity Actions to merge services Near- sightedness Accidental
Adversaries Shifting the Burden
96. Desire to take fundamental solutions Near- sightedness
Actions to merge services Dev velocity Need for improving
architecture Size of a single service instance Stability # services
Need for proper coordination Actions to split services Actions to
enhance anti-fragility Operation complexity Shifting the
Burden
97. Dev velocity Stability Actions to increase operations
eciency # unplanned work Accidental Adversaries
98. Desire to take fundamental solutions Near- sightedness
Actions to merge services Dev velocity Need for improving
architecture Size of a single service instance Stability Actions to
increase operations eciency # services Need for proper coordination
Actions to split services Actions to enhance anti-fragility #
unplanned work Operation complexity
105. Dev velocity Need for improving architecture Size of a
single service instance Stability # services Need for proper
coordination Actions to split services Actions to enhance
anti-fragility Desire to take fundamental solutions Operation
complexity Actions to merge services Near- sightedness Accidental
Adversaries Shifting the Burden
106.
107. (archetype)
108. Accidental Adversaries Shifting the Burden Limits to
Growth Eroding Goals Escalation Success to Successful Tragedy of
the Commons Fixes that Fail Growth and Underinvestment
