 |
| From this photo, you almost cannot see that I was rasmussed by Greg Young |
In fact, as Alberto Brandolini said in the morning, DDD is also about the method, not really about the technology; and the differences in technology between imperative object-oriented languages such as C# and PHP are not so high.
Here are my original articles published this week on DZone.
Practical PHP Refactoring: Replace Subclass with Fields is about the inverse move of refactoring from type codes.
The Goal of software development is an exposition of Goldratt's work applied to software development.
Practical PHP Refactoring: Decompose Conditional is the first article about dealing with ifs and possibly targeting polymorphism.
Temporal correlation in Git repositories contains the code for discovering which classes usually change together in the history of your codebase.
Do you like this article? 
3 comments:
The event was really interesting.
More than ninety percent of each talk was language-agnostic, focused on concepts every programmer can follow.
I was the only PHP dev (except Giorgio) amoung two hundreds .net/java devs, but surely I'll attend again the event next year, and I suggest the partecipation to everyone, whichever tecnology you use (or the role you plate in the company).
Hi Giorgio, unfortunatly I had no occasion to talk with you saturday.
I used to be a PHP developer (I also early joined the effort to translate the PHP4 manual in italian, but the team never completed the work)
However I'm now out of touch with PHP, I moved from PHP after just 6 months of work with PHP 5.
Once I learned C# I started to think that strong typization is a useful tool to enforce business rules...
I'd really like to know your opinion on this matter. Does PHP evolved to a stronger type system in these years?
How do you enforce business rules with a dynamic type system? Don't you have to handle a number of runtime exceptions?
Type enforcement is still optional in PHP (you can specify coercing types for method parameters), but since the language is interpreted and dynamic these constraints are enforced at execution time.
In our domain model, exceptions bubble up to a generic service layer which catches the topmost exception types of the hierarchy, reporting them to the user; the aggregate remains in the previous state since exceptions are thrown during validation of a command or before a change in data is persisted (the object is thrown away at the end of the request: what is not persisted is lost.)
We may risk to forget to catch some exceptions which the service layer, but we are covered by the test suite; it's a general practice for tests to substitute compiler checks in dynamic languages.
Post a Comment