API Platform Conference 2022 - M. Arlaud & R. Chalas - Domain-driven design with API Platform 3

แชร์
ฝัง
  • เผยแพร่เมื่อ 6 พ.ย. 2024

ความคิดเห็น • 7

  • @abdelilahaassou6333
    @abdelilahaassou6333 2 ปีที่แล้ว +1

    Great presentation guys, really full of information.
    Thank you!

  • @josuenguimatio
    @josuenguimatio ปีที่แล้ว +2

    Hi !
    and about migration for entities ?
    in which folder , are we going to place them ?

  • @oOShaoOo
    @oOShaoOo 2 ปีที่แล้ว +2

    Thanks for this conf. Can you give me the GitHub repo, I can't read it at the end of the video.

    • @coopTilleuls
      @coopTilleuls  2 ปีที่แล้ว +4

      Hello, check this out: github.com/mtarld/apip-ddd

  • @АлександрГалицкий-ю6ж
    @АлександрГалицкий-ю6ж 2 ปีที่แล้ว +1

    Thanks for the video!
    I have a couple of questions:
    1. in github repo you've provided as example, the domain models contains Doctrine mapping annotations. don't you consider that as a violation of dependency rule?
    2. as I remember, Api-platform is trying to serialize and pre-validate mapped entities before actual validation constraints. Doesn't that means that infrastructure layer can affect the domain business logic?
    Thank you.

    • @coopTilleuls
      @coopTilleuls  2 ปีที่แล้ว

      Robin speaking:
      Hi,
      1: It’s a tradeoff, see matthiasnoback.nl/2020/09/violating-the-dependency-rule/ and matthiasnoback.nl/2022/04/ddd-entities-and-orm-entities/
      Also as Mathias said: attributes are purely declarative (code doesn’t break if doctrine is not installed) so it's "soft" coupling.
      2. Not in this case since our Api Resources aren’t entities but plain-old data objects located at the infra layer.
      Btw, here are the materials: speakerdeck.com/mtarld/api-platform-con-domain-driven-design-with-api-platform-3.

  • @issussov
    @issussov ปีที่แล้ว

    You got it all wrong. Both DDD and CQRS. I would advice you to rethink how you look at Infrastructure layer. Same for what is actually a domain service and its purpose.