4

At the end of this article from Martin Fowler there is this sentence:

In general, the more behavior you find in the services, the more likely you are to be robbing yourself of the benefits of a domain model. If all your logic is in services, you've robbed yourself blind.

What the whole, very abstract article, doesn't tell you is what exactly goes into the service layer?

As I undestand it the architecture would be something like:

Controller -> Service(s) -> Domain Object(s) -> Repository Object(s)

So what kind of code would go into the service layer if the domain objects implement all the business logic? What would be the difference between the controller and the service layer if the service is not implementing business logic?

floriank
  • 471
  • 2
  • 16
  • mf is just pushing OO programming, which doesnt fit very well into microservice architecture – Ewan Apr 14 '18 at 10:56
  • 1
    @Ewan I've never heard this before. Can you elaborate on why OO doesn't fit well with microservices? – MetaFight Apr 14 '18 at 11:24
  • the stateless nature of microservices and to a lesser extent webpages lends itself to ADM rather than a persisted model graph – Ewan Apr 14 '18 at 11:46
  • ADM = Anemic Domain Model? I'm currently implementing a few microservices following DDD. All the logic (and admittedly there's not much of it) is in the Entities. It seems like a nice fit so far, but I'm still relatively new to microservices. I don't really see the downside to my approach though. – MetaFight Apr 14 '18 at 11:53
  • It depends, for example you can have multiple repositories that provides Domain Objects, each one containing business logic relevant to that domain. A service would then compose new behaviour by acting on the Domain Objects . – holmberd Jul 13 '19 at 18:41

1 Answers1

2

It all sort of rests on where you want to do your coupling and how loose you want it to be. Also, it's not like any of these are absolutes. But if you want to be super DDD about it, thoughtfully consider what a service is. "Edge" services are probably your entry point into an app, but then you have "domain" services below that.

EdgeService -> Domain Object -> Domain Service -> Repository

If your domain objects hold a bunch of domain services that implement strategies for doing "verbs" on each domain object then you've got sort of a regular pattern.

so your edge service would take a blob of json, and make a cow out of it then when you call cow.save() cow finds it's validator service, validates it self, maybe calls it's moo service to moo at the herd, and then uses a repository object to put itself in the barn.

Anywhere you can get a cow object, you have access to all of the functions it presents without having to worry about the collaborating domain services etc: The cow interface would just expose moo() and milk() methods which is all the farmer needs to know about.

lscoughlin
  • 199
  • 2