ORM Tips: Separating Business Logic and Data Logic
Introduction Welcome to another one of my database-centric articles. This time, although all examples will be written in Java, the topic at hand is so generic and universal, it can be applied to any programming language that utilizes any Database Abstraction library that can be called an ORM . Be it Java with Hibernate, PHP with its Doctrine or Ruby with Active Record. Modern Application Architecture has drifted away from layered Monoliths to more flexible and manageable micro-services that utilize Hexagonal approach. Even if you didn't jump into the micro-services train, the focus these days tends to be on good modularization, vertical slicing and defining proper Bounded Contexts and Aggregate Roots within the Business Domain of the developed Product. But does it mean, that a Service or a Module can just be a bag of poorly structured, interconnected Classes with no proper, repeatable and meaningful naming, packaging and responsibilities? Can we, even when using DDD, CQRS and/or