Knowledge-base
  • Home
  • Samman Technical Coaching
  • Software craftsmanship
    • Practices
      • Pair Programming
      • Code Review
      • Co-designs
      • Design sessions
      • Interview Domain Experts
      • Dev ethics
    • The Software Craftsman
    • Egoless Crafting
    • Technical debt workshop
    • Functional Programming made easy in C# with Language-ext
    • F# for OO programmers
    • Domain Modeling Made Functional
    • Testing
      • Clean Tests
      • Improve the design and testing of your micro-services through CDC Tests
        • CDC testing made simple with Pact
        • Pact broker : the missing piece of your Consumer-Driven Contract approach
      • Improve your test quality with Mutation testing
      • How to name our Unit Tests
      • How to write better assertions
    • Katas
      • TDD
        • Stack kata
        • Fizzbuzz
        • Outside-in TDD (London Style)
      • Improve your software quality with Property-Based Testing
        • A journey to Property-Based Testing
      • Clean Code
      • Clean Architecture
      • Write S.O.L.I.D code
      • Mocking
      • Gilded Rose (Approval Testing)
      • Mikado method
        • Mikado kata
      • Pure functions
      • Theatrical players refactoring Kata
        • Let's refactor (OOP style)
        • Let's refactor (FP style)
      • Functional Programming made easy in Java & C#
      • Refactoring journey
      • Refactoring du Bouchonnois
        • 1) Se faire une idée du code
        • 2) "Treat warnings as errors"
        • 3) Let's kill some mutants
        • 4) Améliorer la lisibilité des tests
        • 5) "Approve Everything"
        • 6) Définir des propriétés
        • 7) Tests d'architecture
        • 8) Use Cases
        • 9) Tell Don't Ask
        • 10) "Avoid Primitives" - Commands
        • 11) "Avoid Exceptions"
        • 12) "Event Sourcing"
    • Software Design X-Rays
      • Workshop
    • The Programmer's Brain
      • How to read code better
  • Software Architecture
    • Fundamentals of Software Architecture
    • Aligning Product & Software Design
    • DDD re-distilled
    • Test your architecture with Archunit
    • NoSQL
  • Agile coaching
    • How to run a Community of Practices (COP)
    • The developers — the forgotten of agility
      • The secrets to re-on-board the devs in agility
    • Coaching toolbox
      • Echelle
      • Learning expedition
    • How to improve Team Decision making ?
      • Decision Making Principles and Practices
    • Learning 3.0
    • Retrospectives
      • Back to the Future
      • Mission Impossible
      • Movie themes
      • Rétro dont vous êtes le héros
      • Sad/Mad/Glad
      • Speed boat
      • Star wars theme
      • Story cubes
    • Technical Agile Coaching with the Samman Method
    • Xanpan - a team centric agile method story
    • XTREM WATCH — Découvrez la puissance de la veille collective
    • Become a better speaker through peer feedback
    • Project-to-Product Principles
  • Leadership
    • Bref. J'ai pris une tarte dans la gueule (et ça fait extrêmement de bien)
    • Forward Summit 2020
    • Learn leadership from the Navy SEALs
    • Learn to lead and help your team(s) to be successful
    • Towards a learning organization and beyond
    • Leadership is language
  • Serious games
    • My serious games
    • Libérez vos entretiens d’embauche avec la gamification
    • How to create a game
    • How to debrief a game ?
    • Lego Serious Play (LSP)
      • LSP in your job interviews
  • Xtrem Reading
    • Cultivate Team Learning with Xtrem Reading
    • My Book Infographics
    • How to make book infographics
    • En route vers l’apprenance avec Xtrem Reading
    • Resources
      • Book notes
        • Agile People: A Radical Approach for HR & Managers
        • Agile testing : A Practical Guide for Testers and Agile Teams
        • Boite à outils de l'intelligence émotionnelle
        • Building a better business using Lego Serious Play method
        • Building evolutionary architectures
        • Code that fits in your head
        • Culture Agile
        • Culture is everything
        • Domain-Driven Design: The First 15 Years
        • Dynamic Reteaming - The Art and Wisdom of Changing Teams
        • How to avoid a Climate Disaster
        • La liberté du commandement
        • Réaliser ses rêves, ça s'apprend
        • Refactoring at Scale
        • Succeeding with OKRs in Agile
        • Team Topologies
        • The Good Life
        • Tu fais quoi dans la vie
        • Who Does What By How Much?
  • My Activity
    • Retour sur mon année 2020
Powered by GitBook
On this page
  • Connection
  • Concepts
  • Hexagonal Architecture
  • Onion Architecture
  • What characteristics do these architectures have in common?
  • Use Case Driven Approach
  • Clean Architecture
  • Concrete Practice
  • Objective
  • Part 1
  • Part 2
  • Conclusion
  • Pros & Cons
  • Support
  • Resources

Was this helpful?

  1. Software craftsmanship
  2. Katas

Clean Architecture

A Craftsman's Guide to Software Structure and Design

PreviousClean CodeNextWrite S.O.L.I.D code

Last updated 4 years ago

Was this helpful?

Connection

  • Split the group in 4 :

  • Ask this question

    • What characteristics do these architectures have in common? - 5'

    • Craft as many post-its as they can

  • Review what has been produced

Hexagonal architecture

Onion architecture

Concepts

Hexagonal Architecture

Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases.

Onion Architecture

Layers

  • Domain Model layer, where our entities and classes closely related to them e.g. value objects reside

  • Domain Services layer, where domain-defined processes reside

  • Application Services layer, where application-specific logic i.e. our use cases reside

  • Outer layer, which keeps peripheral concerns like UI, databases or tests

Dependency Inversion Principle (at Architecture Level)

This means that when writing our high-level business logic, we don’t want to depend directly on low-level stuff like databases, file systems, network connections, provider contracts, and such.

Instead, we should expose an abstraction that represents a higher-level business need and implements it using these low-level mechanisms.

What characteristics do these architectures have in common?

Here is some answers to the connection question :

  • Independent of frameworks

    • Does not depend on the existence of libraries

    • Allow us to use frameworks as tools (not a constraint)

  • Independent of the front-end

    • Can easily change the UI (from web to console)

  • Independent of the database

    • Business rules not bound to Database logic

  • Independent of any external agency

    • Business rules don’t know anything about outside world

Business rules can be tested without external components

Use Case Driven Approach

Ivar Jacobson in his book below explained we should map 1 Business Use case / 1 Application Use case. We should implement Application Use Case with the BCE "pattern" : Boundary Controller Entity :

Clean Architecture

The Clean Architecture as expressed by Robert C. Martin is a mix of the 3 architecture ideas explained before :

Entities (Enterprise business rules)

  • Encapsulate Enterprise wide business rules

    • Can be

      • Object with methods

      • Set of data structures and functions

  • Could be used by many different applications in the enterprise.

Use cases (Application business rules)

  • Capture business rules

  • Structure should indicate what the application is, not how it does it

  • Application specific business rules

Interface adapters

  • Set of adapters

    • Convert data from the format most convenient for the use cases and entities

    • To the format most convenient for some external agency such as the Database or the Web

  • In a MVC architecture : Presenters, Views, and Controllers

Frameworks & drivers

  • Frameworks and tools such as

    • Database

    • Web Framework

Glue code that communicates to the next circle inwards.

  • This layer is where all the details go

    • Keep these things on the outside where they can do little harm

The dependency rule

Source code dependencies can only point inwards.

Concrete Practice

  • Checkout the branch “kata-initial”

Objective

Learn and practice the concepts behind Clean Architecture

Part 1

Each participant :

  • Position projects on the Clean Architecture Diagram

  • Draw the sequence diagram of the Register Use Case

    • They can use :

Correction

Part 2

Cover the following use cases and requirements:

  • The customer can register a new account.

  • Allow to get the customer details.

  • Allow to get the account details.

  • Allow to deposit into an existing account.

  • Allow to withdraw from an existing account.

  • Accounts can be closed only if they have zero balance.

  • Accounts does not allow to withdraw more than the current account balance.

You can check in the branch final-solution to see one possible implementation of those Use Cases

Conclusion

  • What benefits do you see?

  • Pros and cons ?

Pros & Cons

Pros

Cons

Plays well with DDD – architecture that builds everything on top of a domain model

Learning curve – People tend to mess up splitting responsibilities between layers, especially harming the domain model

Directed coupling – the most important code in our application depends on nothing, everything depends on it

Indirection – interfaces everywhere!

Flexibility – from an inner-layer perspective, you can swap out anything in any of the outer layers and things should work just fine

Potentially heavy

Testability – since your application core does not depend on anything else, it can be easily and quickly tested in isolation

Support

Resources

Source :

Clone the repository at :

Hexagonal Architecture :

Onion Architecture :

Clean Architecture :

A simple template for Onion Architecture with .NET 5 :

https://blog.octo.com/architecture-hexagonale-trois-principes-et-un-exemple-dimplementation/
https://github.com/ivanpaulovich/clean-architecture-kata-dojo
https://sequencediagram.org/
https://plantuml.com/
https://app.diagrams.net/
https://blog.octo.com/architecture-hexagonale-trois-principes-et-un-exemple-dimplementation/
https://bitbucket.org/jeffreypalermo/onion-architecture/src
https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
https://pereiren.medium.com/a-simple-template-for-onion-architecture-with-net-5-6c0e2f3b29c8
Alistair Cockburn
Jeffrey Palermo
BCE
Uncle Bob's book
Empty Clean architecture Diagram
Register User Case