- One purpose of adopting design patterns in software development is to have the same vocabulary. So we can communicate between our team members using pattern name. For instance, “Let’s create an AbstractFactory for this part of the code….We can use Strategy pattern for that tax calculation.” So we can use the patterns to communicate verbally also to communicate in code the architecture of the system. That means quick coordination inside the team and easy to maintain software.
- If you read Eric Evans’ book on DDD you will realise that Evans had categorized, anything that we can’t call object should be called Service. But you invent you’re own term which is Job and Operation. You’re adding complexity in the system also in the whole world of Software Engineering (read point 1) and it is obvious you haven’t read Evans’ book. Imagine if we all build Software using DDD, we will use the same terms and the code will have similar architecture that is simple to understand and easy to scale and maintained.
