Basically, it's a simple object representation of some kind of reusable data structure. Unlike entity, it does not have identity, so value objects are considered as equal if underlying data is equal.
Want to know more? Read below π𧡠#architecture
Value Objects encapsulate data and ensure its validity - constructor can, and should, check if provided primitive values are correct. Thanks to that, when you pass VO to other methods, you can be sure it carries proper information π
Value Object's reusability doesn't mean you reuse data it carries. You reuse its structure across other Value Objects or Entities. Name can be used for modelling Employee, Client and other.
So you can have several John Doe employees with the same Name, but different Id π
How do you name attributes, methods, if you use private attributes with getters or public, readonly attributes does not matter. What matters is that you should model self-contained, reusable structure that carries data which is always valid for further usage.
Since Value Object is a domain concept, you should mostly use your own models & do not allow 3rd party code to leak into your domain. But in reality you probably don't want to model things that are already done.
So you can use vendor code (or infrastructure, like PHP's), but do it knowingly and with care. Don't populate your domain code with unnecessary dependencies without real added value π
This thread is inspired by @PovilasKorop's tweet, which IMHO provides very misleading example of Value Object. Not only `(new FullName('John Doe'))->fullName()` looks weird, but also idea of using external VOs for this is not good.
π€ Dictionaries: should they be in the database? π€
Dictionary is set of values that are supported in your application. But how they should be defined? Well, as always, it depends π #PHP#architecture
Let me tell you what I think about it ππ§΅
In general, I believe there are two types of dictionaries:
1) Internal, related to your app's logic 2) UI-managable, related to app instance's data
Let's look about difference between them π
Internal dictionaries are represented in the code. With #PHP 8.1+ it's pretty straightforward - you can use enums π When you need to represent some state, string-backed enum is the best choice, because it's much better for debugging purposes.
There were many discussions if #Laravel's facades implement GoF's Facade Pattern, but I think it does not matter at this point - the team won't change naming convention anyway. Naming is not a problem, I see other issues with facades - a #PHP thread π§΅
1) They're basically magic πͺ Some may see it as advantage, but I consider it as drawback. You don't execute exact code you're calling, but your call is proxied to some underlying service. It strictly couples your code with the framework, which handles it.
Facades' API has to be added as comments in PHPDoc (with `@Method`) which is error prone because it's easy to forget to update facade's phpdoc when underlying service (accessor) is changed. But even if autocompletion in IDE works, you just can't simply navigate to method's code.