extracting mutators and accessors to a trait in the application layers) will increase the complexity level and the discomfort of our Laravel programmers. Any implementation that tries to fight this aspect of Eloquent models (e.g. Trying to fight it or add a package that uses a version of Eloquent that is more adequate to DDD will only push us and future developers out of our comfort zone. If it's any consolation to you, this situation might be messy but this is how we've always worked with Eloquent before. This time, we have to choose a side: team DDD, or team Laravel? rule A or B? Using Eloquent within the domain layer can unfortunately not satisfy all of our constraints. The domain model basically becomes a data mapper. The consequence is that the domain will know things about the database - and possibly bypass invariants from our repositories. Public function setTrackingIdAttribute($id) We then use accessors and mutators to generate some domain attributes based on some database attributes. Our $attributes property only reflects the columns of our table. What about when the attributes of the domain do not match the attributes in our database? Some mapping has to happen somewhere right? There is actually a deeper problem to that. Okay let's say we accept implicit attributes. They are actually here for a reason and using them for another purpose feels like hacking the framework. What about using $fillable and $visible to make them obvious? We could, but overriding the constructor with one that accepts arguments will make a lot of Eloquent function fail as most static calls proxy to an empty model using new static, e.g. We might as well use POPOs and data mappers.Ĭan we at least initialize those attributes in the constructor? Without the $attributes property, we miss out on the majority of features provided by Eloquent. Should we add them as class properties anyway and ignore the $attributes of Eloquent? This is very handy when its one hundred but not very convenient in the domain layer where the attributes of an object need to be explicit so that we can reason about them. For example, can you tell me what are the attributes of the following class? class Customer extends \Illuminate\Database\Eloquent\Model The disturbing thing about Eloquent models is that even when they are completely empty, there is already so much they can do. When none of them can be satisfied together, we will prioritize rule B and stay true to Laravel. It is important to keep in mind how important it is to reach a balance in keeping focus on the domain ( rule A) whilst staying true to the framework and, particularly in that case, active records ( rule B). DEFINITION OF ELOQUENT DESIGN HOW TOWe will go through each of these challenges and see how to overcome them if we can overcome them. In fact they are even more dangerous now that the focus on the domain is at stake. Now that we introduced Eloquent to DDD, we did not magically remove all of these constraints. Moreover, in a Domain-Driven environment it completely overshadows the semantic of the model objects by assimilating them as a set of technical draws. It helps surviving a little longer but I don't have to tell you that it does not make miracles in the long term. For example I would have a UserRepository trait with all query scopes inside and a UserPresenter trait with all accessors inside. My solution when the complexity increased was to extract some of the functions into dedicated traits. Not to mention: $fillable, $guarded, $visible, $hidden, $appends, and even some provided by packages. Each had their fair share of accessors getFirstnameAttribute(), mutators setFullnameAttribute(), relationship methods comments(), query scopes scopeActive(), model events static::saving(function($model) ), etc. In various projects I have found myself submerged with Eloquent models that simply became some kind of configuration files. A dangerous decision that I will tackle here ?. This implies allowing the Eloquent beast to enter our domain layer. In a previous article we concluded that, when implementing DDD with Laravel, the Framework itself should become our new programming paradigm in order to leverage all of its goodness and avoid fighting it.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |