Rant to discuss Domain Driven Design (DDD) architecture.

Did anyone implemented on production?
How scalable and easy to use?
Do you recommend it? if yes in which environment? in which business types?

.

@gitpush ?

@Mba3gar to get notification when someone answers, consider it as a bookmark

📌

So it seems many devs here are interested to read and get notified on this subject but no one has already used or experience in it.
Well very interesting

Tripple D's?
Ok no, let's be serious this time.

🤔 I can't say I've had a need to even think of considering DDD as a valid option.

Obligatory 🚩for someone who works in stupidly complex projects.

Bookmarked.

I'm doing some DDD / Onion Architecture electric boogaloo right now. My grasp on DDD isn't that great but I've been involved in building a system using that approach once and I think it's really cool. Not sure what the alternatives are tho, except for the ol' "let's wing it and start building something and hope it comes out right".

Having different representations of the same concept based on context is sweet. Shave off all that bloat and cognitive load. A car means one thing for the person assembling it and another thing for the person selling it; some properties are obviously shared but others are relevant only in one specific context.

I also like establishing a shared vocabulary so that business and tech can communicate clearly, that "Ubiquitous Language" thing. Feels like it leads to a system that closely resembles the actual problem domain.

I'm not used to talking in these terms so I'm having a hard time coming up with more than "DDD good"... So far, I see a lot of promise when dealing with any non-trivial problem/domain. In my current project I try to apply the concept where I can see a clear benefit and just keep it simple so that I don't over-engineer the thing...

.

.

I think DDD works super nicely in 3D games.

🔥

The company I work for is heading towards domain driven design, from what I've found so far the major benefit is the separation of business logic to be able to unit test properly. If you have an application like an accountancy system or something similar, it works great. I can't say much about other software areas though

@Darkovernerd but how easy to use ? What's the difference you found so far ? Why it's currently trending ?

@Mba3gar it all depends on your implementation to be honest. I would recommend reading up on the solid principles and specifically the inversion of control principle and liskov substitution principle.

My guess as to why it's trending is due to the current push in tdd

We have been using DDD for different systems for some time now. In the past we have used the TableGateway/RowGateway pattern, but it created some problems in different areas of the system (to be honest, it was a legacy system, no test cases, etc.).

I'm definitely not an expert on DDD, but generally I like the concept. It allows me to map the business requirements easily into code. I find it easier to make changes to the requirements, because the logic is in a centralized place.

However, I found it was kind of hard to really grasp the concept. On top of that, it requires you to learn how to use the DataMapper of your choosing correctly. Because of those reasons, it can take some time before you are really productive when applying DDD.

When I started with DDD for the first time, I ran into some of the following questions:

1. How the hell am I supposed to achieve X using DataMapper Y?
2. Which objects are the AggregateRoots, and will I run into any problems when I get it wrong.
3. Does business requirement X belong inside the domain or should it be placed inside a service, etc.?
4. It makes no sense at all, why the hell can I not implement this properly using SOLID (answer: generics are missing in PHP)
5. Should I use the specification pattern here, or will a method on a repository be sufficient?

Most of those questions are hard to answer. It really depends on your use case and it requires some practice before you get a feeling for it. But, fear not, I found it was a lot easier to refactor code when using DDD (use a decent editor though).

Overall I never had any regrets and when I look how we did before, we are way more productive than before.