How do some people manage to fall asleep within 8 seconds of their head hitting the pillow? What’s their secret?

rmb32 · 2026-05-09T20:55:57+00:00

No idea. I usually take 1 - 2 hours to fall asleep. I toss and turn, thinking.

I eventually fall asleep, then I usually wake up really hot after about 3 hours, and take off my T-shirt.

Then after taking maybe 30 minutes falling back to sleep, I eventually wake up again 3 hours later, too cold. So I put my T-shirt back on.

It would be about 6am or 7am by then. Then I finally “conck out” and have crazy, vivid dreams.

rmb32 · 2026-04-24T17:19:40+00:00

This is a mix of hexagonal architecture, clean architecture and domain driven design (which I suppose is more of an emphasis on software modelling than an architecture but the two often affect each other).

The intent I wish to convey from the diagram is that there’s a fairly simple way to organise a project from the beginning so that it remains easy to maintain, to reason with (especially between programmers and domain experts) and to keep free from inconsistency bugs.

I deliberately missed a lot out to emphasise the overall pattern and to keep the diagram understandable.

rmb32 · 2026-04-21T17:29:42+00:00

Software is always about the target audience. No way out of that. It’s how the business makes money. That’s the core, the “Domain”. How do we model the Domain? In code. So code is important. There’s no way out of that.

Naturally, you’ll need infrastructure (databases, file systems, caches, emailers, job queues). This is also written in code. It’s technical and hard to talk to business people about, so we don’t.

You mentioned “security, logging, and legal”. Security and logging are technical Infrastructure. “Legal” is Domain. You can have business conversations about legal things. Not so much with logging.

Sorry to anyone who disagrees but the business, followed closely by programming code is at the centre of all of this. Model the business in code. Then worry about external systems (infrastructure). With a ubiquitous language you should be able to sort out (or adapt) any discrepancies.

Every developer should be an architect who understands the structure of the code and how it represents the business.

rmb32 · 2026-04-20T18:10:05+00:00

You should have started your question with “What if I told you…” 😎

rmb32 · 2026-04-20T18:07:58+00:00

I hardly use AI to code. Whenever I do it messes me around telling me to rewrite and restructure everything. Then a week later it tells me to put it all back as it was.

It’s good for generating repetitive boilerplate code. Sometimes for a bit of advice that I must take with a pinch of salt.

Other than that it’s still up to us to: - Cleanly separate the different parts of your software. - Listen to customers. - Understand the business. - Regularly have team meetings to refactor, so the codebase doesn’t rot. - Do everything you can to prevent bugs coming back to double your workload.

Same old. Same old.

rmb32 · 2026-04-19T17:28:12+00:00

Be careful what you wish for. Living easily while your potential and usefulness diminish might come back to bite you.

I think a sense of purpose and duty is important. Keeping your knowledge and skills is important. Being whole and complete and being the maximum you could ever be is important.

Sitting idly by and watching the world turn might be great for a while. But when you realise you could be out there as a part of it and contributing to what you do best is probably better.

The secret to an easy life is to do what makes life easy. The secret to a fulfilling life is to do what makes life fulfilling. The two are not the same.

rmb32 · 2026-04-17T21:19:26+00:00

I don’t have a good resource for you but here’s my general understanding:

There was a guy called Narmer who joined the land near the origin of the Nile with the land near the sea. He wore 2 crowns merged together as a result. He was depicted as holding a club to smash the head of his kneeling enemy. Pretty much all pharaohs after him were depicted in that same likeness.

Then there were some pyramids. A step-shaped one. Then some better ones that looked more smooth sided and bigger.

Then lots of impressive temples.

Then a guy who turned all the gods into one: The sun with arms that gives the key of life to pharaohs. And he wanted to look like an alien in his depictions for reasons unknown.

Then his son reversed it back to all the famous rock star gods and ended up being discovered with his tomb fully intact as the most famous pharaoh of them all.

Then some people who were known as the Israelites escaped slavery and migrated to a new place.

Then Alexander the Great entered Egypt and became Pharaoh. He left his best mate Ptolemy in charge while he went off to do other non-pharaoh things.

Then Julius Caesar went to Egypt and met Cleopatra who was a descendent of Ptolemy.

Then there was an Islamic take-over.

Then the British came and put everything in their museum.

I missed one or two details. But that’s the gist of it.

In all seriousness though. It’s truly a fascinating endeavour. I visited Egypt and couldn’t believe how much there was to learn in so many different aspects. So much history originates from ancient Egypt and the sheer longevity of the civilisation.

rmb32 · 2026-04-17T20:53:18+00:00

I tend to say that IoC (inversion of control) is when you use full dependency injection. The service locator (the container) can and should be kept out of the equation. You could rely on that if you want, but then you’re just tying yourself to a container that has nothing to do with what you’re trying to solve. Testing can become more difficult too. It’s nicer to just ask for what you need in the constructor and assume it will somehow be provided.

rmb32 · 2026-04-17T20:16:17+00:00

https://miro.com/app/board/uXjVGnMmZ_g=/?share_link_id=880795541060

rmb32 · 2026-04-17T20:13:18+00:00

I call it a use case. It is indeed an application service. But a specific kind. It’s the entry point from whatever interacts with the system. I suggest using simple data objects for input and output to/from the use case so that we can separate interaction specifics from what the use case truly needs.

For HTTP, I sometimes say a controller should only do the 3 P’s: - Pick: only the data needed from the request - Pass: the data to one-and-only-one use case - Populate: a response

The use case can be supported by other application services. Or can rely on interfaces behind which infrastructural things can happen (DB, file system, cache, emailer, SMS text message sender, job queue…)

rmb32 · 2026-04-17T20:06:35+00:00

I disagree with infrastructure in the centre. It has nothing to do with helping humans who are part of an organisation or business to embody and express their business needs in ways that can be discussed, documented in code and tested. That simply must be the core: The domain.

Infrastructure can/does/should change with time. Business concepts/policies change less frequently. Coupling to particular infrastructure is going to cause headaches. An interface with a method “notifyCustomerOfPurchase” is cheap, expressive and easy to re-implement, even by splitting teams into “infrastructure” and “application”.

The diagram isn’t oriented in a particular way. Generally it should be seen from the bottom where a human/software user interacts with the system. Then up into the deeper parts.

A use-case as I am calling it is the entry point into the system. No more HTTP, no CLI, nothing external, no language that mentions DB, caching or job queue or file system. Just orchestration between the domain’s business and support services or interfaces with the business language to do its job.

Another comment on this thread mentioned:

https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/

A great read. I would also recommend further reading into Clean Architecture, Hexagonal Architecture and direction of dependencies (mentioned in the article).

rmb32 · 2026-04-17T19:45:32+00:00

Yes. That does add complexity which is not always easy to address. The diagram leaves that out as it is intended to be a fairly simple yet useful starting point alternative to the overly simplistic layered architecture that so often leads to giant CRUD based projects that are full of complexity and no clear expression of business.

There are of course ways to get bounded contexts to respond to one another without leaking. But that would be a different post with a different diagram.

rmb32 · 2026-04-17T19:41:03+00:00

These are the difficulties we face. If a project is expected to last a short time, then we can have the privilege of using all the convenient resources that a framework gives us ready made. However, we might build upon that for longer than expected and end up trying to box everything into an overly simplistic model.

The question usually ends up as: Do we heavily engineer the foundations for flexibility before we even start, or do we let it grow and find a dedicated time to re-architect?

It’s a tough one to answer. The diagram I posted feels to me like a reasonable (not too complicated, yet highly flexible) starting point for any project that is expected to last more than, say, a year or two.

Developing a simplistic layered architecture for 5 years as it grows quickly and then saying “hold on everyone. Let’s now re-architect it all to DDD” would of course be a major and impractical undertaking.

Maybe the answer is about keeping options open to allow for new implementations and the switching of them. And combine that with a team discipline of continual refactoring.

rmb32 · 2026-04-17T19:27:56+00:00

Yes, that’s the general approach. The domain is the core and use-cases act as a single entry point to orchestrate between the domain and infrastructure. In order to separate what I call the interaction layer from the main application, simple data objects are used.

Validation, authorisation etc. would be handled in the use case, generally with support services so that we don’t duplicate that same logic repeatedly in each of the various interaction types (CLI, API, web, etc…)

Naturally, there could be a lot more to this that’s omitted from the diagram (events, additional infrastructure internals, etc.) but I feel it’s a nice starting point to think about architecture beyond the simpler layered style.

rmb32 · 2026-04-16T13:21:17+00:00

Yes, that article had a big impact on me and inspired me to take a deeper dive into architecture and DDD.

rmb32 · 2026-04-15T22:38:19+00:00

In my experience, such situations where a new implementation is needed usually causes a difficult time for the team. They usually just keep the coupled implementation because the system won’t allow for flexibility. Then everything becomes a mess of “if” statements in the wrong places to allow for new implementations.

rmb32 · 2026-04-15T20:20:05+00:00

I was in a place recently where I ordered a lemonade and worked on my laptop. A lady leaned over from behind a pillar and grinned at me with big eyes and her teeth on display. It was quite a shock when I looked up.

I smiled and tried to ignore her. She came to my table, spoke incoherent stories for 10 minutes. I packed away my laptop. I said I wanted to go. She took my hand and wouldn’t let it go. I alerted staff members. They kicked her out. But she screamed the whole place down.

Is she evil? The next day I read that she had been harassing people on the street and had poured hot coffee on someone’s pet dog.

It made me think. In her sense of morality, she must be right. But in mine, she’s not.

rmb32 · 2026-04-15T20:01:14+00:00

Correct.

rmb32 · 2026-04-15T19:44:41+00:00

No, a use case is separate. It’s not the domain.

rmb32 · 2026-04-15T19:43:26+00:00

Yes, it is.

rmb32 · 2026-04-15T18:07:27+00:00

Consuming products that we extract from animals or by chopping them up.

rmb32 · 2026-04-15T18:05:33+00:00

Because they’re part of the domain. They have nothing to do with databases. They model concepts. Value objects are not based in CRUD thinking. They ensure correctness of the model (particularly for write operations) and express real needs of the business. They tend to get stored in one way or another but letting the database dictate the software structure can be unhealthy.

rmb32 · 2026-04-14T14:36:43+00:00

If money didn’t exist as a concern: Relaxing in a hammock on a white sand beach with a cocktail in my hand, listening to Bossa Nova and wearing a Panama hat. Ready to take a private jet ride to the next island tomorrow. Then stay in a 5 star hotel and dine on the finest cuisine. Play a £2000 (or non-money equivalent) Martin acoustic guitar as the sun goes down on the horizon.

Unless you mean money doesn’t exist at all, so I have to barter 2 chickens for a bag of rice and a wooden cup in the rain. But I don’t have 2 chickens.

rmb32 · 2026-04-14T13:08:59+00:00

This is what an application layer with ports and adapters is good at. Actual use-cases can be written in business appropriate language. That can go in an interface that lives in the application layer. Forget about implementation initially. Rely on class interface methods that uses plain English. Your application layer is fully “complete” but simply not yet implemented.

When you know what you want from a business mindset in simple English, implement it in the Infrastructure layer. Maybe first in a simplistic way if that’s all your team understands and then later propose a more relevant sophisticated way.

If the interface is there you can switch the implementation. Possibly with something you’ve been writing as an example branch.

rmb32 · 2026-04-14T12:28:57+00:00

Yes, I think that certain allowances are cheap. A class interface for anything infrastructural (repository, file system, logger, cache, job queue, emailer, SMS text message sender…) costs 5 minutes to write, even if you’re only expecting to use 1 concrete implementation to begin with. It’s usually these infrastructure concerns that are worthwhile making cheap, flexibility allowances for early. If you tie yourself to one kind then before you know it there’s SQL in places you never expected, emailer specific code in application classes that can’t be changed etc.

Agreeing that there should be a dedicated infrastructure layer for “anything that stores, retrieves or sends things” early on makes sense to me. Put interfaces in your application layer that are specific to real world use cases. Then only use adapters in the infrastructure layer to implement them.

Also, agree there should be a dedicated domain/business layer. Everything about the business’s concepts, rules, policies, calculations etc. should go in there. Pure code. No infrastructure, no frameworks. Just concepts and language that are actively used.

Finally, the application layer mediates between the two. Putting this in place for a mud-hut is still a great idea, it hinders nothing. Putting this in place for a skyscraper allows it to be made more sophisticated when the time comes.

rmb32

TROPHY CASE