> How many places in your code create new users, and how many places in your code need to validate users? If the answer is “many,” you have serious design problems that should not be solved by introducing more classes but by restricting how many different areas of code do the same job.
Consider an application where you can edit and add users. Consider that you can also add users to groups and remove users from groups. Consider that you might also be able to add policies to users. These are a few different areas in code where you might need to create an instance of a User.
This is exactly what we're doing; we're limiting the amount of places where valid users can get created. The User domain object and it's invariants are validated right here at the model.
If there was an invariant saying that users can't have more than 5 policies on them, a user.addPolicy(policy) method would exist right on the user model/aggregate root, and the aggregate root would be responsible for determining if any invariants will be unsatisfied after the operation.
> Also, the private constructors do absolutely nothing. The static factory methods in this blog post could be written the exact same way as a constructor, and they would work exactly the same. The only reason the author uses a static factory method is because that's what he was taught to do in Java.
The reason why I use a static factory method is because it allows you to protect the aggregate invariants (domain logic that deems the model to be correct). The language has nothing to do with it.
If I was to create Coordinates, I need to ensure that the Latitude and Longitude fulfill the domain requirements, and I want to be able to know if I was able to create that object or not.
This is a different way of programming, for sure. DDD takes a bit of time to wrap your head around. But when projects are sufficiently complex, it pays off to know that there's no possibility for an invalid aggregate to be floating around at runtime.
> It's just OOP for OOP's sake in a language with tons of features designed for avoiding OOP.
Could not be more incorrect.
If you're interested in learning more about DDD, check out "DDD Distilled" for a quick primer on it and why the chosen patterns are used. There's a method to the madness.
Think of it as like building a Domain-Specific language that any of the 4 developers in your company that need to write code will be able to use without breaking any rules of the domain. If it's just you writing code on a project that is relatively non-complex, DDD is probably not the optimal choice.
Consider an application where you can edit and add users. Consider that you can also add users to groups and remove users from groups. Consider that you might also be able to add policies to users. These are a few different areas in code where you might need to create an instance of a User.
This is exactly what we're doing; we're limiting the amount of places where valid users can get created. The User domain object and it's invariants are validated right here at the model.
If there was an invariant saying that users can't have more than 5 policies on them, a user.addPolicy(policy) method would exist right on the user model/aggregate root, and the aggregate root would be responsible for determining if any invariants will be unsatisfied after the operation.
> Also, the private constructors do absolutely nothing. The static factory methods in this blog post could be written the exact same way as a constructor, and they would work exactly the same. The only reason the author uses a static factory method is because that's what he was taught to do in Java.
The reason why I use a static factory method is because it allows you to protect the aggregate invariants (domain logic that deems the model to be correct). The language has nothing to do with it.
If I was to create Coordinates, I need to ensure that the Latitude and Longitude fulfill the domain requirements, and I want to be able to know if I was able to create that object or not.
This approach usually means using a Result class to handle errors (https://enterprisecraftsmanship.com/2015/03/20/functional-c-...).
I'll be writing another article on that topic.
This is a different way of programming, for sure. DDD takes a bit of time to wrap your head around. But when projects are sufficiently complex, it pays off to know that there's no possibility for an invalid aggregate to be floating around at runtime.
> It's just OOP for OOP's sake in a language with tons of features designed for avoiding OOP.
Could not be more incorrect.
If you're interested in learning more about DDD, check out "DDD Distilled" for a quick primer on it and why the chosen patterns are used. There's a method to the madness.
Think of it as like building a Domain-Specific language that any of the 4 developers in your company that need to write code will be able to use without breaking any rules of the domain. If it's just you writing code on a project that is relatively non-complex, DDD is probably not the optimal choice.