sairyss/domain-driven-hexagon

Domain-Driven Hexagon is more of a long form guide than a runnable application. The author has gathered, in one giant README, a set of recommendations on how to design backend software using a mix of well known approaches: Domain-Driven Design (DDD), Hexagonal Architecture (sometimes called Ports and Adapters), Clean Architecture, Onion Architecture, SOLID principles, and the Secure by Design idea. Code examples in the repository are written in TypeScript with the NestJS framework and a Postgres library called Slonik, but the README is clear that these patterns are framework and language agnostic; the examples just had to be in something. The README opens with a caveat that everything is offered as a recommendation, not a rule. Real projects only use a fraction of these patterns, depending on what they actually need. The author lists the pros: code stays independent of external frameworks and databases, it is easier to test, easier to grow with new features, and it can be split across teams without people stepping on each other. The cons are also stated honestly: the architecture is sophisticated, needs someone experienced to drive it, and is overkill for small CRUD apps because of the boilerplate and abstractions it adds. Most of the guide is then organised into layered sections matching the chosen architecture. There is an Application layer that talks about Application Services, Commands, Queries, and Ports. There is a Domain layer that explains Entities, Aggregates, Domain Events, Integration Events, Domain Services, Value Objects, Domain Invariants, and Domain Errors, with sub topics like making illegal states unrepresentable and the difference between guarding and validating. There is an Interface Adapters layer covering Controllers, Resolvers, and various kinds of DTOs (the data shapes that flow between layers). There is an Infrastructure layer covering Adapters, Repositories, and Persistence models. The README also includes a request flow diagram and a written walkthrough: a request or event arrives as a plain DTO at a controller, gets mapped into a Command or Query, passed to an Application service, which runs business logic through domain services and entities, then talks to infrastructure through port interfaces. Further sections cover advice for smaller APIs, behavioural testing, folder structure and file naming, ways to enforce the architecture in code, advice against deep inheritance chains, and a long appendix of articles, blogs, videos, and books.