Please enable JavaScript.

Coggle requires JavaScript to display documents.

clean architecture - Coggle Diagram

- - - - system, sub-system, layers, components, classes, data
  - - - minimize de cost of developing software and maximize usefullnes, increase return on investment
  - - - essential in solving a domain problem
        
        domain, use cases
        
        details: presentation, persistance
      - samples
        
        no inner layer knows of the outer layer, it's testable without UI or server
      - benefits
        
        focus on the domain - which is essential in solving the use domain pb
        
        less coupling between domain and implementation details ( presentation, persistance)
        
        allows to incorporate domain driven design
      - downsides
        
        more tought to decide what goes into domain and what goes application layer;
        initial cost is higher but pays off if the app has a long lifecycle
    - - modern version - use dependency inversion
      - pros
        
        focus on the use cases
        
        easy to understand
        
        dep inversion
        
        expensive to add layaers?
      - cons
        
        decision on what belongs where
        
        inversion of control is counterintuitive
    - - in real live scenarios is hard to separate commands and queries - e.g. insert a new item - should return the ID
        increases code cleanes
      - single DB CQRS
      - two DB CQRS
        
        the write and read DB should be synced in a matter of miliseconds
      - event sourcing - most complex version of CQRS
        
        save operations/transactions in one db, replay the events in order to get the final version of a data
        
        keep a DB where the final version of the data is computed so read access is fast
        
        it's easy to debug, replay events, can have multiple read databases, can reconstruct events at any point in time
        
        perfect for audit and traceability
      - pros
        
        easy to use for domain driver design
        
        better performance
        
        efficient design
        
        on queries you can bypass domain model to retrieve the data specific for the UI -> this can result in a more performant system
      - cons
        
        inconsistency
        
        more complex
    - - screaming architecture - promotes visibility of the use cases of the app
        
        categorical vs functional cohesion
        
        organize by components(categorical) or use cases (functional)
        functional cohesion is more logical
        use spatial locality - things that are used together are placed together - it promotes better separation
      - cons
        
        loose framework conventions
        
        categorical is easier at first
    - - smaller teams but need good communication and coordination between teams
      - good explanation of domain driven design - even if we have a similar entity in a domain, it could be smart to separate into several entities based on the bounded context
      - how big should a microservice be and where should the boundary be? - use bounded contexts
        allows each team to focus on the single domain knowledge
        high cohesion, low coupling
        microservices allows flexibility in technical decisions ( services can have different architectures)
      - pros
        
        less costly to build a microservice than a whole app - in a long app lifecycle, in theory can reduce cost
        
        cohesion/cupling of application, domain knowledge , DBs
        
        independence
      - cons
        
        high cost at the beginning, better suited for large projects instead of smaller ones
        
        needs communication
        
        distributed communication - latency over network