How to Create Flexible Components with Two Levels of Service Objects
Again I was reminded about the value of service objects to encapsulate sequences in two places: the Domain, where business rules are kept, and in client code, where database management and transactions play a role. This distinction helps create clean code and deliver flexible components. I am building a feature for the Word Counter in a separate “library” project until everything runs smoothly. Then I’ll integrate the code into the main application. Since I consider this to be some kind of library, I thought I wouldn’t need many service objects, but I was wrong.
3 Ways to Model Relationships in a Domain
Let’s assume we need a Domain Model and can’t create our application with basic CRUD actions and data containers. Let’s further assume we have a Box Entity which can contain many Itemn. Item is an Entity, too, because its attributes may change over time, so a Value Object won’t do.