jorge07/symfony-6-es-cqrs-boilerplate

Several things I don't like in this boilerplate

inkuber opened this issue · 2 comments

inkuber commented

Hello. Discussion topic. Feedback needed.

Several things I don't like in this boilerplate

  1. No way to separate bounded contexts. You made architecture slices such as Domain, Infrastructure, Application and UI. But even if I develop simple application I facing with several bounded context such as Authentification bounded context and my business logic. I refactored out Auth bound context to separate folder structure src/Auth/{Application/Domain/Infrastructure} Example
  2. You made specification over uniqueness of email address. But it means that you push repository through interface into business logic making it not pure. Domain layer should be as simple as calculator. I think that using smart types more right. I made factory that returning UniqueEmail type. Only way to get UniqueEmail is from factory that checks uniqueness before instantiating email object. Example
  3. EvenSourcing is extremely complicated thing and people advice not to use it for all project, just for parts that needs it. I made common interface for EventSourcing and CurrentState models for DomainModel. You could choose which implementation to use in services.yaml. My template fork using CurrentState model for authentification, it means that rows in tables created directly, not from events. I plan to make something that will allow to choose which auth model to use, current state or event sourcing.
jorge07 commented

Hey @inkuber

1 - You're totally right. I use to develop very small services and for those this layered structure just works. For bigger ones I flip the structure the same way: BoundedContext/Layers. On the other hand Identity and access management use to be a supporting subdomain inside a bigger one like Customer/Members.
2 - This really depends of your business model, what works for you may not work for others. An specification pattern allows you to define different rules decoupling the implementation. Sometimes works, sometimes it's just too much for the task. So IMO here, it depends.
3 -Yes, not all your business must implemented as ES, but probably the opposite. On the other hand usually User it's core business and this boilerplate illustrate with this example how to implement it. Nothing stops you from CRUD your business here.

I really appreciate your feedback. Seriously thinking about flip the layered structure so you don't have to when projects grow.

jorge07 commented

After upgrade to PHP 8 yesterday I finally decided to go and switch to bounded context first structure. WIP