I've let geepaw know images are missing on his blog.
26.02.2026 09:10
👍 1
🔁 0
💬 0
📌 0
I've let geepaw know images are missing on his blog.
Oh, they are versioned indeed!
"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.
Various folder structures shown in the hexagonal architecture book.
I didn't use to clearly show hexagonal architecture in my folder structure, but reading the book by Alistair & Juan convinced me to start doing this.
I'm still not decided on the name "external". "Adapter" would be too generic but it would match ports better.
Yes, each adapter being in its own gradle project.
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
A good start overall. I'll continue with the approach and see where it takes me.
When I finally decided to agree to suggested changes, it turned out Junie did exactly what I expected it to do, rather than what it it would do, lol.
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.
Junie tough, didn't communicate what it was planning to do accurately.
For example, it told me it's going to remove most of my settings.gradle.kts. It mislead me into thinking it wasn't listening to instructions.
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.
I got excellent results with AI Assistant. It decomposed the steps exactly the way I expected it to.
# 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.
I also taught it how to define general purpose libraries.
^^ this is me teaching it how to define a project module by documenting I expect a hexagonal architecture layout with a distinct domain model inside the application.
## 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.
I use tools available in @intellijidea.com, so I started by giving AI Assistant hints where to look for documentation by defining my first rule in .aiassistant/rules/README.md.
Hopefully, I'll end up with good documentation and a set of micro-prompts to do certain tasks on the project.
Once I have micro-prompts, perhaps I'll be able to start using macro-prompts for slightly bigger tasks.
I guess it's like documenting the project, except I get instant feedback if my writing is well received and understood.
I'm experimenting with AI Assistants to get them to do projects my way.
My approach is document how I'd like things done while I do them. Then I revert the change and let the assistant do it.
Role-playing - objects are more players of their roles than instances of their types.
-- Sandi Metz
#oop
"You can't build the right product if you can't build the product right. If you can build the thing right, you can live long enough to find the right thing."
ronjeffries.com/xprog/articl...
As always, it's great to listen to @jbrains.ca. Are integrated tests a scam?
youtu.be/j0NjFsb-at8
Makes sense to me since what defines the test double is its runtime behavior rather than how the mocking framework or developer labels it.
To stub - I'm using this mock to stub these values.
To spy - I'm using this mock to spy on that important interaction.
To stub - I generated this mock from this contact to stub these interactions.
To design - I'm using this mock helping me to design interactions with this collaborator.
She offers advice on what to do instead: make peace with everyone calling the test doubles mocks, but add a verb for how it is used.
Mocks... Mocks everywhere... In this video Emily made me feel it's ok not to fight this particular instance of semantic diffusion.
youtu.be/RvKPOjlQKyM?...
We Tried Baseball and It Didn't Work ronjeffries.com/xprog/articl...
"You can draw a line around any part of your code and call it anything you like, but only when you have to maintain the tests do boundaries become real."
“Hexagonal Architecture Explained” Alistair Cockburn & Juan Manuel Garrido de Paz
#hexagonalarchitecture #portsandadapters #testing
The Future of Software Development is Software Developers - or why we won't be replaced by #ai anytime soon - by @jasongorman.bsky.social
codemanship.wordpress.com/2025/11/25/t...
Me in 2005: let me code this whole system over the weekend.
Me in 2015: let me glue these open-source projects together to confirm if the idea is worth doing.
Me in 2025: let me spend a couple of hours creating a spreadsheet so I don't have to write the app.
Limited options gave me an unprecedented focus on what's important. I'd have created a better app now that I've created the spreadsheet. The thing is I don't need to as it brilliantly solves my problem.
Spreadsheets are underrated. It might seem that a spreadsheet would limit me in some ways, but its limitations turn out to be a superpower.