Name: Learning Domain-Driven Design
ISBN: 9781098100131

What Hacker News says

skydhashFeb 2026

Not GP, but the most impactful one I read was Learning DDD from O’Reilly

https://www.amazon.com/Learning-Domain-Driven-Design-Alignin...

It presents the main concepts like a good lecture and a more modern take than the blue book. Then you can read the blue book.

But DDD should be taken as a philosophy rather than a pattern. Trying to follow it religiously tends to results in good software, but it’s very hard to nail the domain well. If refactoring is no longer an option, you will be stuck with a non optimal system. It’s more something you want to converge to in the long term rather than getting it right early. Always start with a simpler design.

thread

skydhashJan 2025

The C programming language (ansi edition) - I had it before even leaning how to program properly. The explanations was so clear you could work out the examples with pencil and papers

Mystical man-month and the pragmatic programmer. The former gave insight about managing a team, the other about managing yourself.

Currently I’m reading:

Unit Testing: Principles, Practices, and Patterns by Vladimir Khorikok

Designing Data Intensive Application by Martin Kleppman

And very recently completed Learning Domain-Driven Design by Vlad Khononov

I think the three are quite good too

thread

danneciuOct 2022

Nobody becomes great overnight, it takes years to gain the knowledge and experience to be at the top in your field. These books would help you get there faster.

Here are some of the best tech books I read recently that I believe will make everyone a better Software Engineer:

System Design Interview — An Insider’s Guide

Grokking Algorithms An Illustrated Guide For Programmers and Other Curious People

The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change

Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy

Algorithms to Live By: The Computer Science of Human Decisions

thread

cygnedMar 2021

Great question. I was very concerned about that, too. I strongly recommend learning Domain Driven Design before diving into Spring, you will recognize a lot of patterns and it then makes sense how things work. Even things like having an interface + an implementation for basically everything becomes apparent. I had a lot of bad experience with Spring and Jakarta EE in the past, but I can assure you Spring Boot does a fantastic job here.

Point being, it is an enterprise setup and in enterprise applications you favor maintainability and friends over speed of development. So implementing a feature takes more files and more time, in a DDD setup you can estimate something like 1 controller method, use case + interface, >=2 DTOs, potentially a domain model if not present plus a repository + interface if not present.

So yes, it is more overhead and you have a slow down in productivity. I have no proof, but I am 95% sure that the time you save upfront in a more flexible environment like node is being paid back significantly worse when it comes to maintenance.

Edit: you can of course use Spring Boot without enterprise/DDD and hence make it simpler. It's actually pretty minimal.

thread

neciudanDec 2025

The Real Balance of Coupling, Complexity, and AI in Software Architecture (w/ Vlad Khononov)

We sat down with Vlad Khononov, author of Learning Domain Driven Design and Balancing Coupling in Software Design, to discuss how the industry is still misunderstanding core architectural principles—and why AI makes mastering them more urgent than ever.

Here are the key, hard-won lessons from the conversation:

1. DDD is Not Over-Engineering, But Your Focus is Wrong Many teams fail and call DDD "over-engineered" because they focus solely on the Tactical Design (Aggregates, Entities) and ignore the essential Strategic Design. The core of DDD is not writing beautiful code, but aligning with the business: * The two most important components are Ubiquitous Language and Bounded Contexts. * Ubiquitous Language is the core subdomain of DDD because almost all project failure traces back to communication issues between business and engineering. * Bounded Contexts define the applicability boundaries of those languages, but they are also driven by social decisions—specifically, by aligning with team ownership.

2. The Core Model of Coupling is Three-Dimensional Coupling isn't just "bad design," it's a necessary relationship between working components. The goal is Balanced Coupling, defined by three dimensions: 1. Strength: The amount of non-business knowledge (data format, implementation details) shared across a boundary. The more knowledge shared, the more two components must change together. 2. Distance: The physical or organizational separation (same file/folder vs. different services/systems). High knowledge sharing demands a low distance to reduce the cognitive load and pain of making necessary changes. 3. Volatility: The rate of change in the knowledge source. If the source is low volatility (e.g., an old legacy system, like a checkout or invoices database), you can be pragmatic (e.g., coupling directly to the DB schema).

Balance is achieved when high strength is inversely proportional to distance or when volatility is low.

3. AI Makes Modularity and DDD Non-Optional The LLM era requires us to be better engineers: * Ubiquitous Language makes your LLM prompts more effective. An LLM finds the "average" answer from the internet. If you don't provide explicit, company-specific context (your ubiquitous language), the results will be generic. * Bounded Contexts solve the context window problem. Large systems with high-strength coupling across big distances create pain because it's easy for a human engineer to forget to modify a distant part. An LLM with a limited context window faces the exact same difficulty. Modular boundaries (Bounded Contexts) put related, co-changing things close together, making it easier for the AI to check dependencies.

What "pain signatures" are you using to decide where to apply DDD?

Listen to the full episode here: https://www.youtube.com/watch?v=_DpUqjTyPM0

thread

meaboutsoftwareAug 2024

Hey HN,

I just wanted to share that after five months of intense work and countless caffeine-fueled writing sessions, "Master Software Architecture: A Pragmatic Guide" is now available.

Writing this book was a crazy time. I entirely focused on it, and it took exactly 753 hours of writing, editing, and image editing & resizing(!) until the premiere.

Yes, the last one (images) was a killer. If you ever think about writing a book, reserve a lot of time for it unless someone else does it for you.

As a result, I am handing you the nearly 400-page book. It is a guide that will help you connect all the pieces while balancing the focus on understanding the domain and technology aspects, described using a pragmatic approach and super simple language.

It is perfect for novice architects taking their first steps in software architecture. It is also an invaluable resource for software engineers looking to understand architectural concepts and those considering transitioning into an architect role.

Several guest authors, including Vlad Khononov (Learning Domain-Driven Design book), Oskar Dudycz (Marten, Emmett, Pongo), and Milan Jovanović (.NET & C# educator), shared their views on keys to successful software architecture.

Here you can find a free chapter (the first link on this page):

https://www.fractionalarchitect.io/books/master-software-arc...

To your success, Maciej "MJ" Jedrzejewski

thread