law: ninety percent of everything is crap most of what we built was mediocre even we care high quality, we do not know what it really is we believe in common explanations written in blog posts we do not dare to take the time to understand it in depth
a result, it has degrees Systems are prone to entropy. In software, as in nature, complexity increases unless work is done to maintain order - Fred Brooks (Author of The Mythical Man-Month) the goal of development should be keeping software predictable & less chaotic
today to refactor later write code to never delete, extend whatever it takes customer needs should fi t our existing design modular design is a good design
in a step-by-step process. The more steps needed, the more "assembled" and complex the object. Assembly happens over time, and a complex object re fl ects a history of its construction process Assembly theory allows complexity to be measured by counting the steps required to create something. 1 2 3 Assembly Theory concept from physics & biology to explain how complex systems arise through a process of sequential assembly
complex systems arise through a process of sequential assembly Software is developed by assembling reusable modular components, that is functions, classes, libraries, multiple layers, integrations, APIs, and components interacting in de fi ned sequences Technical debt can be viewed as steps in the assembly process that happen in time with complexity leading to future problems 1 2 3 Abstraction simpli fi es the assembly process, making complex systems easier to build by reducing the amount of detailed assembly required Refactoring and automated testing are the process of simplifying the structure, making the steps of assembly clearer and more maintainable 4 IN SOFTWARE DEVELOPMENT CONTEXT independent, interchangeable, a part that constitutes a whole
folders breaking code into smaller pieces adding new layers of abstraction high cohesion, low coupling event based architecture layered architecture using oop drawing and focusing on boxes using microservices completely decouple components having modules code will be modular by …
& increase modularity by balancing coupling =( ) the formulation of the reduction of entropy Reference: Balancing Coupling Software Design book, by Vlad Khononov
Coupling in Software Design book. The book deserves to be in the top 10 in software design. I cannot recommend it more. Do yourself a favor, get it now and read it to the end. twitter.com/lemiorhan/status/1841903400117797271 - Lemi Orhan Ergin
other integrated in the system upstream component downstream component purpose business functionality bounded context interaction contract system boundary knowledge magnitute all the degrees between weak and tight interconnected set of components having a purpose habitat of knowledge how familiar about each other passing knowledge out of boundaries cohesion type of coupling, grouping related business capabilities together in a single module or bounded context provides a functionality to be consumed consumes upstream’s functionality interface exposing knowledge balancing
integrated in the system coupling working functionalities never guarantee future growth and fl exibility without having the right balance in coupling upstream component downstream component purpose business functionality bounded context interaction contract system boundary knowledge magnitute loose/weak, tight/strong interconnected set of components having a purpose habitat of knowledge how familiar about each other passing knowledge out of boundaries cohesion type of coupling, grouping related business capabilities together in a single module or bounded context provides a functionality to be consumed consumes upstream’s functionality interface exposing knowledge balancing coupling higher degree the more knowledge modules share, the higher likelihood that they will need to change together
DISORDER straightforward predictable best practices documented insuf fi cient info known unknowns consult expert search for help insuf fi cient info unknown unknowns no expert no one knows no best practice context speci fi c experiment trial and error unpredictable inconsistent no experiments no consulting trust your instinct transform to complex no awareness cannot categorize cannot understand disorganized unmanagable investigate to learn how dif fi cult it is to understand, explain, or predict a system or model validating a web form submission peformance optimization in database queries user experience design sudden crash of a server uncertainty encountered when starting a new project
it is in everywhere tight interactions, more components, high cognitive load uncontrolled complexity leads to chaotic CLEAR COMPLICATED COMPLEX CHAOTIC DISORDER
or options a system, function, or program can adjust or change how much control or fl exibility you have when working with something more degree of freedom means more fl exibility, but more shared knowledge and more complexity FREEDOM HAS CONSEQUENCES
size or the number of components, but the unpredictable (non-linear) interactions between components. It is not the number of components that produces complexity, but the interaction among them. - Charles Perrow professor of sociology at Yale University on organizational theory and the sociology of risk https://press.princeton.edu/books/paperback/9780691004129/normal-accidents
cells, operating on their own isolated state, and communicating via message passing The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. Alan Kay from Alan’s email about “Prototypes vs Classes” h tt p://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html ALAN KAY’S SCHOOL OOP objects were originally designed as modules
public interface/api to other modules WHAT? Implementation Details implementation, algorithms and design decisions hidden from customers HOW? Context environment that de fi nes the relationship of the module with other modules WHERE? WHO?
into modules. Those modules had very complex interfaces, and changes almost always affected many modules. - David L. Parnas pioneer on modularity and information hiding in software systems that’s where DDD means a lot!
Reference: Balancing Coupling Software Design book, by Vlad Khononov Payment API MASTER REPLICA Report API Save payment Retrieve payment Generate report Search payment Read Write Read QUEUE produce event consume event Vlad uses “integration strength” to mean what I mean by “coupling”. - Kent Beck from Vlad’s Balancing Coupling book
Coupling Software Design book, by Vlad Khononov Payment Installment pos selection algorithm pos selection algorithm Playground pos selection algorithm API API Methods in the same object Objects in the same namespace/package Objects in different namespaces/packages Different libraries Services in a distributed system Systems implemented by different vendors close: far: coherence bigger cognitive load
Reference: Balancing Coupling Software Design book, by Vlad Khononov Even the most pristine system may evolve into a big ball of mud over time, as changing requirements, developer turnover, and lack of refactoring take their toll. - Brian Foote and Joseph Yoder, Big Ball of Mud essay https://www.researchgate.net/publication/2938621_Big_Ball_of_Mud
Reference: Balancing Coupling Software Design book, by Vlad Khononov A timeless goal of software engineering has been to separate code that changes frequently from code that is stable. - Jim Coplien, from Lean Architecture book https://www.amazon.com/Lean-Architecture-Agile-Software-Development/ dp/0470684208
Reference: Balancing Coupling Software Design book, by Vlad Khononov If your model is telling a story, the modules are chapters. It isn’t just code being divided into modules, but concepts. - Eric Evans, the pioneer on Domain Driven Design https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity- Software/dp/0321125215
Coupling Software Design book, by Vlad Khononov for the sake of managing maintenance, cost and stability strength distance volatility HIGH HIGH HIGH HIGH HIGH LOW HIGH LOW HIGH LOW HIGH HIGH LOW LOW HIGH HIGH LOW LOW LOW HIGH LOW LOW LOW LOW high global complexity loose coupling maintenance effort HIGH LOW LOW LOW HIGH LOW LOW LOW unstable high cohesion unchanged legacy system stable, loose coupling low cost, high cohesion low cost, stable, local complexity high local complexity balanced
Coupling Software Design book, by Vlad Khononov for the sake of managing maintenance, cost and stability strength distance volatility HIGH HIGH HIGH HIGH HIGH LOW HIGH LOW HIGH LOW HIGH HIGH LOW LOW HIGH HIGH LOW LOW LOW HIGH LOW LOW LOW LOW high global complexity loose coupling maintenance effort HIGH LOW LOW LOW HIGH LOW LOW LOW unstable high cohesion unchanged legacy system stable, loose coupling low cost, high cohesion low cost, stable, local complexity high local complexity balanced UNBALANCED
Coupling Software Design book, by Vlad Khononov for the sake of managing maintenance, cost and stability strength distance volatility HIGH HIGH HIGH HIGH HIGH LOW HIGH LOW HIGH LOW HIGH HIGH LOW LOW HIGH HIGH LOW LOW LOW HIGH LOW LOW LOW LOW high global complexity loose coupling maintenance effort HIGH LOW LOW LOW HIGH LOW LOW LOW unstable high cohesion unchanged legacy system stable, loose coupling low cost, high cohesion low cost, stable, local complexity high local complexity balanced HIGH STABILITY, LOW COST
and maintenance of the system over time. That means that the architecture must balance modularity and coupling. Systems that are tightly coupled or poorly modularized become increasingly hard to sustain over time. - Robert C. Martin from the book “Clean Architecture”
kpriemer
zastrow
erunyon
orderedlist
