2

I m trying to learn how to make my code better. This way, I try to learn some books and understand them.

I m having some troubles dealing with Domain Objects. From the first year of my IT school, I've learnt to create some UML diagrams, and more particularly class diagrams.

When I need to represent the following user story on a class diagram :

"As a user of the application, I need to list all of my clients"

I can translate it to the following (approximative) class diagram :

enter image description here

One of my business rule is to check that a Client (that ows a contact email property) has a mail formatted with some extension, and a special format.

Dealing with my colleagues, it seemed to be a good idea to store it in a service, so that we can control it in multiple ways, and being able to reuse it in another place of my application.

It's okay for me. But...

If we think all the code with all our constraints and methods in our services, we only have POJO instead of Domain Objects.

My Domain Objects are not less not more than a list of properties, representing a value, probably taken from a storage mechanism, but without having any behaviour, only data.

From my example, I only store email inside of Client class, and I don't have anything other.

So, I need to ask you, in which case will I put some methods and behaviours inside of my domain objects instead of in my services ?

Can you provide me a clear example so that I can understand ?

EDIT : Can you tell me if this makes sense :

From what I've understood, it seems that Application Services are the unique entry point to my domain / infrastructure, poviding APIs. Its role is like "aggregating" infrastructure services and domain services.

Domain services are most of the time "stateless" and provides only way to validate data (business rules ? Specification Pattern ?)

Infrastructure services are here to deal with the outdoor (injecting repository for data access, mailing, sending sms etc...)

Can you validate, or at least provide more informations about this ?

Thanks for your help.

  • 1
    See also: Services in Domain-Driven Design (DDD) – Erik Eidt Sep 6 '16 at 15:22
  • Thanks for this. It's a bit difficult for me to understand the key differences between these services... I've edited my question. Can you tell me if my expectations make sense ? – mfrachet Sep 6 '16 at 18:10
  • 1
    Yes, Domain Models provide basic stateful capabilities, and when necessary Domain Services part of the domain, and stateless, provide a domain-oriented choreography among multiple Domain Models. – Erik Eidt Sep 6 '16 at 18:16
  • 2
    For me, it is hard to talk about Infrastructure Services in the same breath as Application Services and Domain Services because they go to a different dimension of factoring, which is more concrete and about layering of implementation whereas the other two go to a more abstract factoring of front-end (application) and persistence+business logic (domain). For example, I would not try to show all three on the same architecture diagram; I'd have at least a second diagram to show infrastructure services. – Erik Eidt Sep 6 '16 at 18:18
  • 1
    There's lots of state even in a stateless services. Code, configuration, etc... all represent state of sorts. There's also state within the handling each individual request, of course. Still, when we say stateless, we generally are referring to the absence of the kind of business-oriented state that carries over from request to request; think records in a (disk or memory) database, for example, e.g. inventory. A domain service with that kind of state would be a domain model... – Erik Eidt Sep 6 '16 at 19:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.