Please enable JavaScript.

Coggle requires JavaScript to display documents.

Clean Architecture (Common thoughts. (Charachteristics of architectures…

- - - - Don't allow frameworks to rule your architecture.
      - Frameworks are tools, not the true or only way.
      - Frameworks forces you to couple your business objects to them.
        Don't let them do it.
    - - Data access frameworks allow us to receive an object from the database record.
        
        It couples the use cases, business rules, and in some cases even the UI to the relational structure of the data.
- - - - The granule of reuse is the granule of release
    - - Gather into components those classes that change for the same reasons and at the same times.
      - Separate into different components those classes that change at different times and for different reasons.
      - This is the Single Responsibility Principle restated for components.
    - - Don’t force users of a component to depend on things they don’t need.
      - Don’t depend on things you don’t need.
  - - - Allow no cycles in the component dependency graph.
    - - Depend in the direction of stability.
      - Less stable components should depend on more stable components
    - - A component should be as abstract as it is stable.
- - - - Encapsulation
      - Inheritance
      - Polymorphism
    - - SOLID
        
        Goals
        
        Creating structures which tolerate to changes and easy to use and understand
        
        SRP: The Single Responsibility Principle
        
        A module should have one, and only one, reason to change.
        
        A module should be responsible to one, and only one, actor.
        
        OCP: The Open-Closed Principle
        
        A software artifact should be open for extension but closed for modification.
        
        LSP: The Liskov Substitution Principle
        
        If for each object o1 of type S there is an object o2 of type T
        such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T
        
        It is explain how to detect and extract subtypes
        
        If you'll exchange using of one type with any of its subtypes
        
        ISP: The Interface Segregation Principle
        
        Dymanicly typed languages are more flexible cause their source code dependencies constructs in runtime instead of compilation moment
        
        Code should see only interface that it needs to use
        
        DIP: The Dependency Inversion Principle
        
        Any source code dependency, no matter where it is, can be inverted.
        
        Independent deployment for different layers
        
        We have absolutely flow control(decide what direction of dependency to choose)
        
        Most flexible systems are those in which source code dependencies refer only to abstractions, not to concretions.
        
        Code practices
        
        Don’t derive from volatile concrete classes
        
        Don’t refer to volatile concrete classes. Refer to abstract interfaces instead
        
        Inheritance is a dependency too
        
        Don’t override concrete functions
        
        Never mention the name of anything concrete and volatile.
        
        Factories
        
        Response for creation instances and uses to manage concrete dependencies
  - - - Have no concurrency problems
    - - Immutability of variables
        
        We can segregate application to
        immutable(function part) and mutable
        
        The more memory we have, and the
        faster our machines are, the less we
        need mutable state.
- - - - Presenters helps us identify and protect architectural boundaries.
    - - As an architect you can break the YAGNI principle to create a boundary placeholder, if you see the place for it.