| In my anecdotal experience, attempting / allowing "true OO" programming turns quickly into an unreadable, unmaintainable, unreliable ball of mud. After leading a team of ~30 developers in a monorepo for the past 5 years, I have been relatively successful in avoiding complete software entropy by enforcing the following "code commandments": - Modular, layered codebase (for ex: interfaces -> service layer -> DAO layer) - Business Logic resides in Service Layer - Service Layer made up of collection of Transaction Scripts (https://martinfowler.com/eaaCatalog/transactionScript.html) - Simple, immutable domain model, with distinct set of immutable objects for each layer. Unapologetically, this is an "Anemic Domain Model", but with separation and no re-use between layers. This allows for immutable objects at each layer. - Services are decoupled and composed around the data / logic, thereby "owning" their own data. Services can communicate with each other to get data, DAOs are never to be shared among other services. This is in a sense, "microservices without the network". - Testing at every layer, while respecting the "test pyramid" (https://martinfowler.com/articles/practical-test-pyramid.htm...). Bang for buck is important here. - Last, but certainly not least: Composition Over Inheritance. |