onion architecture

src: Fetching Title#yc3c

Abstract

What do these architectures (Hexagonal / Onion / Clean) have in common? It’s about the rules.

Domain as the application core:

• independent of the of any framework
• independent of user interface
• independent of any database
• testable
• possibility of change
• domain language

Onion architecture

• incoming: API
  • HTTP controller
  • Kafka consumer
  • CLI
• Application core
  • Application service
  • Command handler: command to give to the system, to dispatch to the right business rule
  • Query handler: fetch view or projection to display to the users (CQRS like)
  • Domain layer ← not present in the hexagonal architecture
    • Domain services: pilots multiple domain models
    • Domain models: business entities, …
    • Repository: interact with those domain models to fetch them somewhere
  • Use case: orchestrate the application + domain layers
• outgoing: SPI

  • Message bus

  • ORM

  • Mailing

Dependencies goes inward

Screaming architecture

The architecture of an application should tell what it does just by opening it. When you look at the top level directory structure, and the source files in the highest level package.

package by features:

• FeatureA
  • ControllerA
  • RepositoryA
  • ServiceA
  • ModelA
• FeatureB

  • ControllerB

  • RepositoryB

  • ServiceB

  • ModelB

solution, as long as the problem is clear. Keep things understandable is more important than naming the architecture.

Vocabulary and human interactions are by far more essential than those architectures. Domain-oriented architecture is a

Functional unit tests

He suggests using JGiven, a Java library to write tests in a “Given / When / Then” format.

JGiven also produces some reports that can be readable by non-technical persons.

Project example used during the presentation: GitHub - ecattez/rent-car-example.