Better Software Design with Clean Architecture
This design puts entities in the middle - everything else pivots around entities. Additionally, it uses the OO approach of implementing logic as methods on the entities.<p>After a couple of decades of experience, I&#x27;ve come to the conclusion that this isn&#x27;t right. Most business rules involve processes, which are inherently procedural, or, from another perspective, functional - functions of the whole state of the system to a new state of the system. Most processes don&#x27;t logically belong on an object, and when you stick them to one end, you create lots of problems for yourself.<p>Just take that example Student entity class; what stops you from writing:<p><pre><code>    student.RegisteredCourses.Add(course);
</code></pre>
Moreover, when you have a relation between two entities, it&#x27;s not uncommon for the relation to be modelled at both ends; that is, a student has a list of courses, and a course has a list of students. Do you implement the same validation at both ends? Make one end (choose one) read-only? Do edits done on one end automatically turn up on the other end? How do you protect the visibility of methods that keep either end in sync, without exposing invariant-violating APIs to other code?<p>Invariants and validations for fields are trivial with an OO approach; for entities, they&#x27;re reasonably easy, but sometimes you need partially invalid versions while editing or constructing an entity; but once you bring in multiple entities, and relations, everything starts getting hairy pretty quickly. Assertions and validations that would be trivial to write [1] in a relational language like SQL aren&#x27;t possible in an object-oriented language without a lot of system-building.<p>So I&#x27;ve come around to the idea that the database is a better thing to put at the centre; that encapsulation and hiding of the main fact store is harmful to the architecture of a system, especially in a heterogeneous environment where your entities are represented in different languages, all backed by the same fact store.<p>[1] Trivial to write, but not necessarily cheap to evaluate. I&#x27;m not advocating writing all global validations in SQL.