- Design smells:
- Immobility
- Viscosity: how easy is to add design-preserving code to a system
- Needles complexity
- Dependency management principles:
- SOLID
- Component cohesion principles
- Component coupling principles
- A responsibility is a source of change for one particular actor, thus they are tight to actors and not individuals
- Payments -> Lawyers
- DB operations -> DBAs, architects
- Reports -> Accountants
- Colocation of reponsabilities couples actors
- Software should be open for extension but close for modification
- Modify by adding new code and not by changing code
- Do not over engineer the design, it is better to wait for the change and from there see what other things are likely to be changed
- Big design up front is not good, is hard to modify in the future, agile design is better
- Design huddles before writing code are useful
- This principle is the moral center of a system architecture
- This principle is about asymmetry of usability
- Inheritance for static typed languages and Duck typing for dynamic languages
- The representative rule
- Representation of things does not share the relantionships they represent, square/rectangle and divorced/lawyers examples
- Some violations:
- If functions of subclass is empty and the parent class implements them
- Check if it is a type instance:
- Avoid whenever is possible, only do it when the compiler forgets what it is and you already know
- This is called
typecase
, this is likely a violation of this principle
- First minutes is a good overview on how to architect an app
- Dont depend on things you dont need
- You can have a class inheriting from multiples interfaces/classes
- Dont force user/caller to know things they dont have to
- This principle addresses Fat classses problem
- Interfaces has more to do with the classes that use them than the classes than implementes it
- Inversion of source code dependencieas against flow control
- A plugin architecture is about inverting dependencies
- Frameworks follow this principle, since they work as a plugins
- High level policy should not depend on down level details (DBs, webs, formatting)
- DBs, UI, etc should be plugin to the application
- Gather requierement by listening to the customer, consider maming the architecture based on use cases:
- Enumerate use cases
- List entities
- Define data structures (including bussines rules)
- Define actors/modules so you can partitionate
- Casting might be needed to dont violate The Liskov Substitution Principle
- Too many interfaces are not bad, they do not have executable code
- One aproach to break dependencies between modules apart of using interfaces, is to write builders (i.e. requests) and factorys (i.e. use cases)
- Class diagrams:
- Useful to share thought process to other people
- They are very easy to get outdated and rot