1. Framework design
   1. App Architecture Guide
   2. A Language for Software Architecture
   3. An Architect Makes It To The Big Show
   4. Cross-Cutting Concerns
   5. Layer
      1. Presentation
      2. Distributed
      3. Domain service
      4. Data access
         1. ORM
            1. NHibernate
            2. Entity Framework
      5. Database
   6. Technical selection
2. Project management
   1. Process
      1. Agile/Scrum/XP
   2. Monitoring
   3. Technical debt
3. Design
   1. Functionality
   2. Non functional
      1. Performance
      2. Scalability
      3. Security
         1. Authorization
         2. Authentication
      4. Disaster Recovery
      5. Backout Plan
   3. Identify risk
      1. Are there risks in the project that could be minimized by an early design activity?
      2. 1. It’s someone else’s responsibility to do requirements.
      3. 2. I learn the domain as I write the code; incrementally.
      4. 3. The requirements are already fully understood by the stakeholders.
      5. 4. Domains are irrelevant to architecture choice.
      6. 5. I already know the requirements.
   4. ARCHITECTURAL PATTERNS
      1. Modules
         1. What is the structure of the actual modular units of code?
         2. How are larger modules decomposed into smaller sub modules?
         3. What other modules are using any given module?
         4. Are the modules structured in layers?
         5. What is the class structure of the modules (e.g. class inheritance)?
      2. Components and Connectors
         1. What is the structure of the actual runtime elements and their various interactions?
         2. How are various processes or threads connected?
         3. Where can threads run concurrently?
         4. Where might threads compete for resources?
         5. How is data produced and consumed by runtime elements?
      3. Allocations
         1. How does the system relate to elements like the hardware, file systems, networks and development teams in the environment?
         2. Where is software deployed (e.g. to what hardware are software elements allocated to)?
         3. How is software mapped to the file system(s)?
         4. Which developers or development teams are assigned to work on a given structure?
   5. patterns
      1. anti-patterns
   6. WHAT MAKES A GOOD ARCHITECTURE?
      1. The architecture should be designed to meet a prioritized list of quality attributes.
      2. The architecture should be driven by the non-functional requirements of the system .
      3. The architecture should be well documented and easily communicated.
      4. The architecture should identify any significant conflicts or tradeoffs, and clearly define the resolutions to these issues.
      5. The architecture should maximize the ability to localize changes to any given part of the system without affecting other parts of the system.
      6. The architecture should, whenever possible, lean on established architectural patterns which have proven most effective at solving the problems the software system is faced with.
      7. The architecture should utilize architectural patterns such that, as often as possible, the system does similar things the same way throughout the entire system.
   7. Bad Design
      1. rigidity
         1. it’s hard to change a part of the system without affection too many other parts of the system
      2. fragile
         1. when making a change, unexpected parts of the system break (introducing bugs)
      3. immobile
      4. Viscosity
         1. Easy to do wrong things, hard to do right things
      5. Needless complexity
         1. complicated class design, overly generalized
      6. Opacity
         1. hard to understand
   8. Layer architect
   9. Principles
      1. SOLID
      2. DRY
      3. KISS
      4. You aren't going to need it.
      5. Law of Demeter
      6. The Cooperative Game Principle
      7. The Peter Principle
      8. Once And Only Once
      9. Design By Contract
      10. open-closed-principle design conventions
          1. All member variables should be private
          2. No global variables
          3. avoid multiple if-then-else or switch-case statements
      11. Principles of Package Design
          1. Reuse/Release Equivalency Principle
          2. Common Reuse Principle (CRP)
          3. Common Closure Principle (CCP)
          4. Acyclic Dependencies Principle (ADP)
          5. Stable Dependencies Principle (SDP)
          6. Stable Abstractions Principle (SAP)
      12. Coupling and Cohesion
      13. Proximity Principle
      14. The boy scout rule
      15. Separation of Concerns (SoC) Principle
   10. Object Oriented Concepts
       1. Data and Logic together
       2. Inheritance is the last option
       3. Composition over Inheritance
       4. Focus on smart data-structure
       5. Abstraction as design mechanism
   11. Class design
       1. coupling
          1. Number of class that your class depends on
       2. Cohesion
          1. the object is focused on doing one thing well
       3. high cohesion and low coupling
4. quality
   1. Code Quality
      1. Code review
   2. Poor Software Quality
      1. Lack of domain knowledge
      2. Lack of technology knowledge
      3. Unrealistic Schedules
      4. Badly engineered software
   3. measure the system quality
      1. 1- Software-quality requirements must be established before the design take place.
      2. 2- Software-quality metrics must be identified.
      3. 3- Software-quality metrics must be implemented.
      4. 4- The results of these metrics must be analyzed.
      5. 5- The software-quality metrics must be validated.
   4. Metric
      1. 1. Source Lines of Code (SLOC)
      2. 2. Bugs per code_section/module/time_period
      3. 3. Code Coverage
      4. 4. Design/Development Constraints
         1. Class/method length,
         2. Number of methods/attributes in a class,
         3. Method/constructor parameter counts,
         4. Magical number, string usage in code files,
         5. Comment lines percentage etc.
      5. 5. Cyclomatic Complexity
   5. Mistakes
      1. Management
         1. 1.- Believing that productivity is mainly associated with man power and working hours.
         2. 2.- Not managing customer expectations.
         3. 3.- Ignoring feedback from developers.
         4. 4.- Controlling as opposite of empowering.
         5. 5.- Being afraid of making decisions.
      2. Managing crises
      3. Effect on Productivity
   6. Technical Debt
      1. How much is it Really Costing you?
         1. $$$ Making a fundamental mistake in architecture or the platform technology
         2. $$-$$$ Error-prone code
         3. $-$$ The system can’t be easily tested
         4. $-$$ Not taking care of packaging and release and deployment
         5. $-$$ Code that mysteriously works, but nobody is sure how or why
         6. $-$$ Forward and backward compatibility adapters and compromises
         7. $-$$ Out of date libraries and middleware stack
         8. $-$$ Duplicate, copy-and-paste code
         9. $-$$ Known, outstanding bugs in code and unresolved static analysis findings
         10. $-$$ Inefficient design or implementation
         11. $ Inconsistent use of programming idioms and patterns
         12. $ Missing or poor error handling and exception handling.
         13. $0.01 Hard coding, magic numbers, code that isn’t standards compliant, poor element naming, missing comments
         14. $0.01 Out of date documentation
         15. $0.00 Hand-rolled code that could have and should have been done using built-in language features or libraries, or existing framework or common services.
   7. Principle
      1. Quality from the start
      2. Early interface validation
      3. Divide and conquer
      4. Safety net for the code
      5. Confidence = Productivity
      6. Light at the end of the tunnel
5. process
   1. Harveynash High level design process
   2. Harveynash Detail design process
   3. Harveynash development process
   4. Harveynash build process
   5. Agile
      1. principle
      2. Avoid
6. must read
7. TA role
   1. Characteristics of a software architect
   2. Are You a Software Architect?
   3. Software Architecture and Related Concerns
   4. What is a good software architecture in a nutshell?
   5. The Hidden Architectural Driver
   6. Clean Architecture
8. checklist
9. Coding