Born before Internet, started as "webmaster", now supporting people mastering it.
I was shaped by XP methodology & DDD architectures. Open source enthusiast.
thank you very much for your constructive feedback. You are totally right. I'll be trying to iterate on them, I don't know if I would edit or post a second one.
The service layer, It is common to discriminate: application service from domain service. It was confusing me when I started. I was used to SOA with a unique service layer.
Basically: Domain service are usually "pure service", like "pure function". Meaning they externalise complexe cross entity logic but they are usually stateless.
For instance: Shipping cost estimation working with an "order", a "shipping address" and a "shipping method". This could be a good domain service. The good part: domain service are easily unit testable. And we like to have domain logic covered by them.
Application (service) layer: these are the handlers in a command pattern approach, and it saved me from so much headaches trying to organise my code.
To be honest, I'm not even quite sure how I would manage a plain DDD project without the command pattern. I would have to implement application service layer to manipulate the persistence, name them (the hardest part) and their methods. Would probably be really messy.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
thank you very much for your constructive feedback. You are totally right. I'll be trying to iterate on them, I don't know if I would edit or post a second one.
The service layer, It is common to discriminate: application service from domain service. It was confusing me when I started. I was used to SOA with a unique service layer.
Basically: Domain service are usually "pure service", like "pure function". Meaning they externalise complexe cross entity logic but they are usually stateless.
For instance: Shipping cost estimation working with an "order", a "shipping address" and a "shipping method". This could be a good domain service. The good part: domain service are easily unit testable. And we like to have domain logic covered by them.
Application (service) layer: these are the handlers in a command pattern approach, and it saved me from so much headaches trying to organise my code.
To be honest, I'm not even quite sure how I would manage a plain DDD project without the command pattern. I would have to implement application service layer to manipulate the persistence, name them (the hardest part) and their methods. Would probably be really messy.