Kuba

@kuba.zalas.pl

340 Followers 190 Following

Software Engineer https://zalas.pl

The user is calling me out on the "Digest" and "Backlog" examples I cited from Evans. I need to be honest here. I cannot verify those specific examples from Chapter 9. The web search results support the general thesis of the chapter (making implicit concepts explicit) but don't mention "Digest" or "Backlog" as named examples. I was wrong to present them as concrete Evans examples without being able to verify them. Yes, I did. I presented "Digest" and "Backlog" as specific Evans examples based on pattern-matching from my training data, but I couldn't verify them against the source. That was wrong. I should have said "I recall examples in this area but can't confirm the details" rather than presenting unverifiable specifics as fact. The general thesis — Chapter 9 is about making implicit concepts explicit — is correct. The specific examples I named were not. I'll avoid citing unverifiable specifics going forward.
JSON formatted response shown to the end user.
"The folder structure is not covered by the pattern, nor is it the same in all languages. Some languages (Java), require interface definitions. Some (Python, Ruby) don't. And some, such as Smalltalk, don't even have the concept of files! That said, we’ve observed that folder structures that don't match the intentions of the pattern end up causing damage. You can create greater clarity by implementing them in a certain form." Excerpt From hexarch v1.1b 20250420-1012 paper+epub alistair cockburn This material may be protected by copyright.
Folder structure: - `app` - the application - `domain` - domain model - `build.gradle.kts` - `ports` - application ports - `inbound` - primary/driving ports – provided interfaces - `build.gradle.kts` - `outbound` - secondary/driven ports – required interfaces - `build.gradle.kts` - `service` - application services, including use cases - `build.gradle.kts` - `external` - adapters for external systems - `inbound` - primary/driving adapters - `outbound` - secondary/driven adapters
Update on task progress The project is a Gradle multi-project build. I've analyzed the README.md and settings.gradle.kts files. The README.md specifies a project module structure based on Ports and Adapters architecture: • app ◦ domain ◦ ports ▪ inbound ▪ outbound ◦ service • external ◦ inbound ◦ outbound Each of these (except possibly placeholders) should have a build.gradle.kts using buildlogic.kotlin-library-conventions. settings.gradle.kts has an includeAllFrom function that automatically includes subprojects containing build.gradle.kts. I need to create the reporting module with this structure.
What I’m going to do To create a new project module called reporting following this repo’s conventions, we need to: Add includeAllFrom("reporting") to settings.gradle.kts (so Gradle auto-includes all subprojects under reporting/**/build.gradle.kts). Create the standard Ports & Adapters folder structure under reporting/. Add build.gradle.kts files for the subprojects (using the provided template). Add a reporting/README.md documenting the module’s purpose.
# Library modules The `lib` folder is where general-purpose library modules live that are not project-specific, or need to be shared between projects. ## Creating a new library The steps below are based on an example library called `example`. 1. Create a `lib` subfolder for the new module named after the library name. Use lowercase letters and single words when possible. Otherwise, concatenate multi-word names and keep them lowercase. 2. Create a `build.gradle.kts` file in the module folder. ```kotlin plugins { id("buildlogic.kotlin-library-conventions") } ``` 3. The new library will be included from the root-level `settings.gradle.kts` automatically.
## Project structure The project is structured as a Gradle multi-project build with each project module being made of several own Gradle subprojects. Additional libraries may be created as subprojects under the `lib` project. ### Project modules Each project module should have the following structure to communicate the use of the Ports and Adapters architecture as well as a commitment to a distinct Domain Model. - `app` - the application - `domain` - domain model - `build.gradle.kts` - `ports` - application ports - `inbound` - primary/driving ports – provided interfaces - `build.gradle.kts` - `outbound` - secondary/driven ports – required interfaces - `build.gradle.kts` - `service` - application services, including use cases - `build.gradle.kts` - `external` - adapters for external systems - `inbound` - primary/driving adapters - `outbound` - secondary/driven adapters `build.gradle.kts` indicate subprojects that will be included automatically when a call to `includeAllFrom` function is added to the root-level `settings.gradle.kts` next to the existing calls. The following `build.gradle.kts` template should be used as a starting point for each subproject: ```kotlin plugins { id("buildlogic.kotlin-library-conventions") } ``` In addition, the `app:service` module should depend on `app:domain`, `app:ports:inbound`, `app:ports:outbound` modules. `inbound` and `outbound` folders in `ports` and `external` folders are placeholders for future port and adapter modules.
# Documentation guidelines README.md files document the purpose of significant folders and modules. ## Libraries For any task in this project related to working with a library, first read the lib/README.md as well as any other README.md files found in related libraries, summarise constraints, then proceed. ## Project modules For any task in this project related to working with subprojects/modules, first read the top level README.md as well as any other README.md files found in related subprojects/modules, summarise constraints, then proceed.
Contract Test Describes the Contract and exercises the System Under Test (SUT). The Contract Test abstracts implementation detail behind intention revealing names. The concrete test case that implements the Contract Test provides implementation details.
Testing iceberg shows tests that benefit the developers (technical) below the water-surface, and business-readable tests above the surface. The iceberg is divided to three parts: tests that verify components in isolation (1), tests that verify integrated components or subsystems (2), end-to-end system tests (3). Most of 3, half of 2, and tiny bit of 1 is above water (business readable). Most of 1, 2, and tiny bit of 3 is below water (technical).
Whoops, something went wrong: status: 500 error: Internal Server Error
A laptop on a background of a very green garden in spring.
Leaning tower in Pisa
Triangle. The base of the triangle is titled “number of tests”. The arrow pointing up from the base to the tip of the triangle is titled “how much of the application the test exercises”.
actor with state implementation
actor with state test case
actorFor implementation
val actor = actorFor("Initial state") { message: String, state -> state + message }
Document written in Obsidian that embeds diagrams created in Excalidraw
Date picker
Oppo Find X8 Pro
Book cover for Understanding Eventsourcing
Example in Kotlin
Data / calculations / actions
Behaviours that depend on other behaviours
Using test containers to connect to the database
Getting the database connection
Populating the database
I/O behaviours
Throwing an exception
Verifying an exception being thrown
Throwing an exception
Mutable object
Test case for a mutable object
Mutable object
Implementation
Test case for a value object
Immutable object
Implementation
Test case for a calculation
Behaviour = input + output
Data
Behaviours all the way down
fun execute(command: GameCommand, game: Game): Either<GameError, NonEmptyList<GameEvent>> { if (game.isWon()) { return GameAlreadyWon().left() } TODO() } data class Game(val guesses: List<Guess>, val outcome: Outcome) { fun isWon() = outcome == Outcome.WON }
val state = events.fold(null, ::applyEvent)
fun applyEvent(game: Game?, event: GameEvent): Game? = when(event) { is GameStarted -> Game(event.secret, Outcome.UNRESOLVED) is GuessMade -> game?.copy(guesses = game?.guesses + event.guess) is GameLost -> game?.copy(outcome = Outcome.LOST) is GameWon -> game?.copy(outcome = Outcome.WON) } val state = events.fold(null, ::applyEvent)
(State, Event) -> State
(Command, State) -> Either<Error, List<Event>>
fun execute(command: GameCommand, game: List<GameEvent>) : Either<GameError, List<GameEvent>> { if (game.isWon()) { return GameAlreadyWon().left() } TODO() } private fun List<GameEvent>.isWon(): Boolean = filterIsInstance<GameWon>().isNotEmpty()
(Command, List<Event>) -> Either<Error, List<Event>>