Symfony2 implementation

[romaricdrigon]

Hi,

A lot of fuzz is going around DDD + Symfony2 framework.

I think it would totally make sense to create a repository with recommendations about implementing DDD with Symfony2.
IMO, it should be a list of recommendations, articles and ressources (eventually bundles) ordered by topic and "severity".

Most importantly, it would be a starting point for discussion and debate.

I would like to work a little bit on that one, though at the moment there is no repository for. Anyone could create it or add me?

[cordoval]

👍 interested in the approach taken

[tyx]

I guess we could start discussion here ?

[cordoval]

well, this is not symfony specific. Imo I think the approach should be in a symfony related repository, so not here. But honestly I don't see symfony as the centerpiece, and we should probably be careful as DDD implies practices such as decoupling from framework 👍

[romaricdrigon]

I think it could get messy really quickly. We could be using an issue per topic for discussing.

[romaricdrigon]

Even better, we could be discussing on some PR. Sometimes writing stuff is the better way to get feedback and provoke reactions.

[cordoval]

👍 for creating a neutral repo

[shouze]

👍 ok guys, very good initiative. From our perspective with @tyx we're on the DDD way. I started long time ago this repo https://github.com/PhpFriendsOfDdd/specs it's not talking about Symfony. I can create another repo if you will, first of all in this case we have to name it, let me know.

[cordoval]

I am in 👍

[codeliner]

Symfony2, ZF2, Laravel, ... = Application layer
DDD = Model
What exactly do you want to achieve with this repo?

[cordoval]

it will be a practical example of how a team of interested and enthusiast world spread devs can build a very simple use case using CQRS + Event Sourcing + DDD using FOSS libraries and completing each other knowledge. Like a sandbox example. I vote for symfony independent (100% symfony-free) repo, but ultimately I care the less about what framework gets used 👍

[shouze]

@codeliner DDD is not just Model, it's also the Application layer, the one decoupled from any framework.

[codeliner]

@shouze yes and no. Sure DDD also influences the application layer and it is definitly more than just implementing a Model, but their should be no differences in implementing DDD with Sf2, ZF2 or plain PHP. Design decisions should be made based on the business not on the tools I want to use. Let's take my php-cargo-sample as a reference. You can put the CargoBackend in a Sf2 Bundle and it would look the same. More interesting questions are: Why should I use ES instead of an ORM. What is the difference between using CQRS and Application Services, etc. That is the reason why I asked what is the expected outcome?

[cordoval]

I think @codeliner asking those questions up front is undesired. The answer is that you cannot tell whether is good or bad for your project unless you see it in action and understand it. For that reason unlike a regular real life project this is a forced exercise, you don't have to pose any reason or fake scenario to force you to take decisions on business. This is a bad and typical answer I get on many mailing lists on DDD, they talk about domain and domain and never show the matter, for that let's use the mailing lists. For learning the methodology I say let's just force frame it that we ARE going to use CQRS and Event Sourcing, the answers to why will come at the end when we see how they work and understand every piece of possible or more common scenarios.

Asking too many questions up front is killing the learning of many and imo it blurs a simple field. Yes it makes people that understand more in shape for their consulting businesses but it does not help people that just want to learn it.

EDIT: by the way, nice example on the cargo, will check it closely

I would propose to tackle similar to Cargo and do it in symfony2 this time since that can rid of the time spent to understand that application layer which is softly relying on symfony2 DI. Other than that it will not be looked on as a dep but as just a practicality.

[codeliner]

@cordoval Asking questions is one of the most importants things you have to do when you want to apply DDD :-). Don't understand me wrong. I got your point, but I see a lot of these DDD + Framework xyz repos, but no one helps me getting better with DDD it just helps me in getting better with Framework xyz. What I think is a really good idea is this project: https://groups.google.com/forum/#!forum/opendddshop, but unfortnately I can't see any progress their.

[cordoval]

i think rather than disagreeing we understand each other better with this discussion we need to discuss more 👍 so yeah let's create the repo somewhere and focus all discussion there, then spike it with some code, but let's go by parts and build a plan first. The questions can go but in issues and discussed, but those who want to stab things and propose can do so with code too. It can even be multiple branches with different approaches.

[codeliner]

👍 sounds good. Count me in as one who will ask questions :-) and perhaps also provide some answers ... Even if I'm not a Sf2 dev.

[texdc]

👍 for decoupled repo. What context(s) will be modeled? That's a valid question before spiking any code.

[romaricdrigon]

We all agree that one of the core principle of DDD is decoupling the domain model from infrastructure concern.
The goal of such repo is to host documentation about how to deal with that "abstraction interface" with Symfony2. For instance, how to deal with the Form component when you don't have any getter and setter.

@texdc for now I was thinking about a documentation-only repo. But why not putting some code example, though I'm not confident about putting an entire application. The bloatness of the framework make those examples harder and longer to explore.

Something I really want to emphasize is about the different "levels" of DDD. I really don't want to go, at least in this repo, into a full-steam DDD application. Actually, as a developper, I have yet to have a project 100% DDD. I've never went into one.
My goal is to have some code snippets and ressources explaining different tactics (because in the infrastructure isolation it is mostly about the tactical side) to tackle some precise issues, eventually having and comparing several ways.

[codeliner]

@romaricdrigon Can we also agree that these problems are not related to Sf2 only? My suggestion would be to use the repo linked by @shouze above. Looks like this repo is very close to your idea, except the Sf2 focus.

[cordoval]

we can use a rewrite i believe as a starting point

[romaricdrigon]

@codeliner no they definitively are. I would not explain how to prevent Symfony Form component from working directly on entities otherwise. A SF2-centric repo is the place to be.

But again I'm opposed to give explanations on a full application. Only very precise points. I don't want to do an app and tell "this is the way to do a SF2 app with DDD". Others have done that.

[cordoval]

I think snippets won't help too much. So I am against just snippets. It has to be a simple app.

[shouze]

Ok so let's focus more on this repo to know how to name it first! ;)

Could be kind of a cookbook repo with many many apps in it no?
It could start with very small apps focused on some specific business use cases.

Why small apps? Because:

1. Easy to understand
2. Quicker to develop

For example:

• A film rating SEO friendly app: each film should have a deeplink url to its profile with a very cool slug into generated from the film name. We need to ensure of the slug uniqueness. It's not that trivial depending on the way you do it. in ES it can imply Saga concept and process manager.
• An accounting app which gather debit/credit from flat files and build a dashboard about your bank accounts.

Every app can be implemented with any framework. Better than that, pure business code can be shared between various implementations of the same app with any framework.

What do think?

Of course in few months if this repo has some success (eg many many stars) we could switch to more complex apps like the Cargo one.

[shouze]

@cordoval I see you read in my brain ;)

[romaricdrigon]

I'm not it for small apps. 50 lines of code can explain much. I don't want to mind reading more to understand a concept.
Symfony2 applications using DDD tend to rapidly grow, with a lot of classes and folders, it's too much.

I think there's a rightful need for an example application, but I don't think it should be the starting point.
Also "doing the right way" an application, agreeing on every single way to do/pattern, is way too much consensus we will hardly reach.

Let's use DDD strategy there, decouple concerns! You don't need to see services to understand how to use the FOSUserBundle in a DDD app.

[cordoval]

tbh i hope we don't use that FOSUB! let's focus perhaps on a similar app like @codeliner and rewrite it and even document the approaches, no need to go on starting splashing random things all over without being cohesive either

[codeliner]

👍 This is exactly the way the various cargo samples work. They look all the same just written in Java, C#, Ruby, PHP, ... I've just replaced Hybernate with Doctrine and Spring with ZF2, but the logic is the same. Have a simple app with a decoupled domain layer served by different PHP MVC stacks would be nice. I'm also interessted in a react php version :-) with promises and so on.

[codeliner]

@romaricdrigon I agree with you, that you will have noise in a full app example made by the framework but on the other side I think it is hard to understand CQRS or ES without looking at a fully implemented use case because you need to see how different components and concepts work together.

[romaricdrigon]

I also agree on that one.
But my scope here is not CQRS or ES, but only DDD. And even less, the tactical part of DDD.
It deeply think than introducing the 3 at the same time is a huge overload for any person. And only a fraction of projects candidates for DDD would benefit from that kind of architecture.

[cordoval]

I actually think CQRS and ES the right way is very simple, and I think it should be part of the scope. Doing DDD without these I believe falls back to what is already available elsewhere.

[codeliner]

Maybe a mix of both approaches can work. I tried this with the cargo sample: Having a sample application on the one hand and documentation for specific problems on the other hand. It worked great to have the codebase in place and point to it from documenation. For example how to handle value objects with doctrine. @romaricdrigon Your Sf2 Form topic could also be explained this way: Instead of passing data from a Sf2 Form to an entity, it is better to pass the data from the form to an command and send this command via a command bus to your model ... Here is an example how we do this in our example application: link to controller which receives request, uses form for validation and sends the command

[DHager]

My team is actually doing Symfony2+DDD+CQRS at work right now, and most of the DDD stuff is in its own separate composer project which is pulled in as a dependency. Using Command/Event DTOs helps with the isolation. (No Event Sourcing, that's just a bridge too far, just Doctrine and a DB.)

In this mode, the Symfony part is responsible for:

• Creating Commands, inspecting Events
• Wrapping the work into a transaction
• Linking their IoC containers so that DDD command-handlers and services have access to infrastructure and concrete implementations of stuff like loggers and repositories.
• Overlaying Doctrine XML/YAML configuration onto the entity-classes (which are not annotated)
• Enforcing optimistic-locking on entities
• ... All the non-DDD UI crap everybody always needs, like populating dropdown menus.

Symfony controllers/views can directly use the DDD-Entities for pulling out data for the UI, but the expectation is that no direct changes are made, they're just a convenient way to get data out of the same tables.

[romaricdrigon]

@DHager I think we share the same approach.
My goal is to get something started documenting "how to" bootstrap and set up all those patterns.

[DHager]

One issue I see is that any demo that sharply separates the Domain core from the MVC side will -- if you're using composer -- also need two separate Git repositories. This has implications in terms of how you want to document or present things through Github.

[v0d1ch]

This is very interesting project. Personally I would love to see how would popular bundles like FOSUserBundle fit in with the DDD project organization. I would love to see full implementation of that in DDD type app as well as Forms offcourse. I guess the world will be a better place after that :)

[tyx]

In his current state I really don't think you could easily use FOSUserBundle or any others "big win" bundle in a full DDD project. And you may not use FOSUserBundle at all

It starts to have some resources about Symfony and DDD but no real full demo application I agree. But even with demo, you should mentally change many thinks in the way of thinking and no better solution to give a try yourself and go step by step.

[v0d1ch]

You are right @tyx I guess you can't have all.

[DHager]

With respect to the 11-month-old project I wrote about before, I've been trying to find time to make a similar-but-open-source demo.

Basically, sectioned off into:

• General Domain library
• Example business domain
• Symfony integration library
• Example symfony application