I was talking with a friend another day about OOP in small projects. In the most of projects that me and him worked the SOA was the rule.
Per example, imagine a Order in a SOA application. The scenario of this application could be:
- A lot of services (UpdateOrderService, CreateOrderService, etc) calling each other.
- The data of the Order is all open (lots of getter and setters) to be manipulated for any Service.
- The business rules are distributed in many Services.
As Vaughn Vernon said in one of his books, this kind of strategy will not work well for bigger projects with more complex business rules. Many of us know that too.
By the way, SOA have a lot of different meanings and I'm taking the simple one, described by Vaughn Vernon: service classes calling each other.
The most obvious alternative is Domain Driven Design, right? But boy, this answer for a simple problem remembers me this phrase: "that escalated quickly". When you compare a simple SOA vs DDD, we are introducing a LOT of new patterns and complexity:
- Unit of Work
- Value Object
And etc. I already work in a big C# project using DDD. Was a amazing experience and opportunity for learn, but is not practical introduce all these concepts in a smaller project.
There is an approach called DDD-lite, but I can't find good or more detailed examples about it.
In DDD-lite territory, One of these examples not address one of the main problems that appears in some projects: use database entity as a domain object. For me this is a mistake, because is not possible to maintain the entity updated with the constant changes of the model and it will be mixed with another abstraction soon or later (like the use of VOs to represent some models). I see the entity only as a place to save/update/delete and search informations.
And, for me, this translation between database and domain is one the major challenges to create an OOP project. With all object associations and operations (create, update and delete), I couldn't find a simple way to introduce this in a project.
So, my question is: there is a midterm between SOA and DDD to introduce a OOP concept in the application without maintain them on the Services?