Hexagonal Architecture and Domain Driven Design
It’s a shame that Domain Driven Design and Data Driven Design have the same acronym, while being basically polar opposites (some people call the latter Data Oriented Design for this reason).<p>To me, Domain-Driven is sort of an extension of Object-Oriented fundamentalism that used to reign, especially in the Java world.  You make a class or a micro-service for every concept in your world.<p>It’s a great way for a huge team of programmers to write a massive amount of code that doesn’t do very much (there are always exceptions, of course!) - with elaborate contortions to model and name everything just right.  You might wind up needing things like Dependency Injection frameworks, mocking frameworks for tests, etc.<p>Data-Driven is the idea of leaning in to the fact that fundamentally, your software is a program, running in computers.  It is going to turn some input into some output.  You design along the axis of what data you need, how it is represented, where it needs to go, what transformations need to be applied, what output needs to be produced, and what needs to be stored.  It tends to look more like functional programming, although you can certainly also apply mutating transformations, usually for efficiency.<p>IMHO, the latter is a great way for smaller teams to produce modest amounts of code that accomplishes a great deal.