Posts tagged with ddd
In this sponsored talk given at Laracon India 2023, I demo all major Oh Dear features. After that, I share how the Laravel app behind Oh Dear is structured using domains.
The audio quality is not perfect, but it should still be understandable.
– www.juststeveking.uk - submitted by Steve McDougall
In a typical Laravel application we are very used to doing things in a certain way, by the book as they say. However there comes a point in the applications lifetime that it is going to be easier to start looking to split this code into Domains so that we can logically group our code.
Read more [www.juststeveking.uk]
Join thousands of developers
Every two weeks, I share practical tips, tutorials, and behind-the-scenes insights from maintaining 300+ open source packages.
No spam. Unsubscribe anytime. You can also follow me on X.
This is a very nice talk given by Eric Evans at DDD Europe 2018. He argues that sometimes try to solve a problem, without reaching to existing solutions, might provide good insights.
It's been over a year in the making and I happy to say it's here: the Laravel Beyond CRUD book and video course are now available.
Read more [stitcher.io]
A couple of days ago my colleague Brent published a blogpost on Domain Oriented Laravel. In short, he makes the case for organising your code around business concepts or features. That might sound very "heavy" or daunting, but it's actually for easy to get started with.
In this short video I explain how you can use PhpStorm to refactor your code. Make up your own mind if you need this in your projects.
Christan Stettler wrote an interesting post on why domain events and event sourcing should not be mixed up.
Event sourcing and domain events can of course be used both at the same time, but should not influence each other. The two concepts are used for different purposes and should therefore not be mixed.
Read more [www.innoq.com]
My colleague Brent shares how we've been structuring our non-trivial projects at Spatie.
In this post we'll look at a different approach of structuring large code bases into separate domains. The name "domain" is derived from the popular paradigm DDD, or also: domain driven design.
Read more [stitcher.io]
Here's another excellent post by Matthias Noback.
Reuse-in-the-small is definitely possible. Reuse-in-the-large is deemed to be impossible, because no two problems/projects are alike, but practice proves otherwise. There are reusable components covering entire subdomains, which are nonetheless quite successful. The chance of success is bigger if such a reusable component is used to cover for a generic subdomain. Using an off-the-shelf solution in such a case helps you save development effort which can instead be redirected to the core domain.
Read more [matthiasnoback.nl]
In another cool blogpost, Matthias Noback explains a few best practices around newing up objects, illustrated with some great examples.
Consider the following rule: "When you create an object, it should be complete, consistent and valid in one go." It is derived from the more general principle that it should not be possible for an object to exist in an inconsistent state. I think this is a very important rule, one that will gradually lead everyone from the swamps of those dreaded "anemic" domain models. However, the question still remains: what does all of this mean?
Read more [matthiasnoback.nl]
In an older, but still very interesting article, Mattias Verraes has some interesting thoughts on form, command and model validation.
Many of the frameworks I’ve worked with, promise to separate responsibilities with MVC. In practice, they end up coupling everything to everything. The forms are coupled to the models, and there’s a grand unified validation layer. This may be convenient at first, but it breaks down for larger systems, and creates headaches when having to support multiple clients. My approach is to clearly separate the validation for the form itself, from the Command validation and the model validation.
http://verraes.net/2015/02/form-command-model-validation/
On the Hackernoon site Nicolò Pignatelli wrote a good guide on how to write Value objects in a good way.
This is the list you must always check it against:
https://hackernoon.com/value-objects-like-a-pro-f1bfc1548c72
On his blog Jef Claes, organiser of DDDBE, shares some good tips on how to organize a meetup.
I've organized a few DDDBE meetups in the past, and always succeed in forgetting something. Either someone points it out well in advance, or I end up stressing last minute. This post partly serves as a checklist for myself, but it would be a welcome side effect to also see it encourage others to help out organizing future meetups. Organizing a meetup is not rocket science, having a list of what to take care of is a good start.
Mathias Verraes, one of the organizers of DDD Europe, recently gave a talk at DDD London on how to name things to both improve your code and to improve communication with the business.
“Make the implicit explicit” must be one of the most valuable advices I ever got about software modelling and design. Gather around for some tales from the trenches: stories from software projects where identifying a missing concept, and bringing it front and centre, turned the model inside out. Our tools: metaphors, pedantry, type systems, the age old heuristic of “Follow the money”, visual models, and a healthy obsession with language.
Nicolas Widart, author of Asgard CMS, created a new package called laravel-modules that can help splitting up a large Laravel app in modules.
On his blog he published an introductory post.
Just imagine having a medium sized application where everything is in the `app/ù folder, worse, every model is in the root of the app folder! At some point you will spend a lot of time looking for things because everything is bunched together.This is what being modular is trying to resolve. You split of the business logic into different parts, which belongs together. If you're into Domain Driven Design, you can consider a module an aggregate.
Every module has its own routes/controllers/models/views/business logic/etc. Meaning every module contains a group of classes that all are related to each other in some way.
https://nicolaswidart.com/blog/writing-modular-applications-with-laravel-modules
I believe that the true value of what Eric Evans wrote years ago lies in the fact that virtually anybody can use some of the things he proposed. They don’t require any special tools, money, approval or reorganization. Those are simple things that you can start doing from next Monday (or tomorrow).http://weronikalabaj.com/ddd-ultra-lite/