際際滷shows by User: saratry / http://www.slideshare.net/images/logo.gif 際際滷shows by User: saratry / Mon, 29 May 2023 08:09:53 GMT 際際滷Share feed for 際際滷shows by User: saratry The aggregate is dead! Long live the aggregate! - SpringIO.pdf /slideshow/the-aggregate-is-dead-long-live-the-aggregate-springiopdf/258098161 theaggregateisdeadlonglivetheaggregate-springio-230529080953-42e5d6a9
https://2023.springio.net/sessions/the-aggregate-is-dead-long-live-the-aggregate/ SARA PELLEGRINI - AXONIQ MILAN SAVIC - AXONIQ DDDs definition of Aggregate may seem somewhat confusing - An aggregate is a cluster of associated objects that we treat as a unit for the purpose of data changes. Okay, lets try to clarify - You should consider your aggregate as a unit of consistency in your Domain.. That doesnt help either. As a matter of fact, while modeling our systems, we tend to group together events related to the same domain concept; we tend to define groups based on the nouns we find inside our events name: saying this is our aggregate!. According to the aggregate definition, we should instead ignore these nouns, and put together the data that change together. Easier said than done: in the modeling phase it is easy to make mistakes trying to identify the boundaries of our aggregates based on this rule. If we opt for saving the state of our aggregate as a series of events, we are in big trouble - any (serious) refactoring of the aggregate structure becomes close to impossible. The reason for this trouble is that we have to make a decision in the design phase for which we cannot be lenient. We are basically married to this decision forever. Due to the aforementioned reasons (and many others), people struggle with the Aggregate pattern. Some even say it is unnecessary, we are one of those. Lets see whether we can model our business constraints without aggregates. Could we be more relaxed when consistency is in question? Join us to discover how!]]>
https://2023.springio.net/sessions/the-aggregate-is-dead-long-live-the-aggregate/ SARA PELLEGRINI - AXONIQ MILAN SAVIC - AXONIQ DDDs definition of Aggregate may seem somewhat confusing - An aggregate is a cluster of associated objects that we treat as a unit for the purpose of data changes. Okay, lets try to clarify - You should consider your aggregate as a unit of consistency in your Domain.. That doesnt help either. As a matter of fact, while modeling our systems, we tend to group together events related to the same domain concept; we tend to define groups based on the nouns we find inside our events name: saying this is our aggregate!. According to the aggregate definition, we should instead ignore these nouns, and put together the data that change together. Easier said than done: in the modeling phase it is easy to make mistakes trying to identify the boundaries of our aggregates based on this rule. If we opt for saving the state of our aggregate as a series of events, we are in big trouble - any (serious) refactoring of the aggregate structure becomes close to impossible. The reason for this trouble is that we have to make a decision in the design phase for which we cannot be lenient. We are basically married to this decision forever. Due to the aforementioned reasons (and many others), people struggle with the Aggregate pattern. Some even say it is unnecessary, we are one of those. Lets see whether we can model our business constraints without aggregates. Could we be more relaxed when consistency is in question? Join us to discover how!]]> Mon, 29 May 2023 08:09:53 GMT /slideshow/the-aggregate-is-dead-long-live-the-aggregate-springiopdf/258098161 saratry@slideshare.net(saratry) The aggregate is dead! Long live the aggregate! - SpringIO.pdf saratry https://2023.springio.net/sessions/the-aggregate-is-dead-long-live-the-aggregate/ SARA PELLEGRINI - AXONIQ MILAN SAVIC - AXONIQ DDDs definition of Aggregate may seem somewhat confusing - An aggregate is a cluster of associated objects that we treat as a unit for the purpose of data changes. Okay, lets try to clarify - You should consider your aggregate as a unit of consistency in your Domain.. That doesnt help either. As a matter of fact, while modeling our systems, we tend to group together events related to the same domain concept; we tend to define groups based on the nouns we find inside our events name: saying this is our aggregate!. According to the aggregate definition, we should instead ignore these nouns, and put together the data that change together. Easier said than done: in the modeling phase it is easy to make mistakes trying to identify the boundaries of our aggregates based on this rule. If we opt for saving the state of our aggregate as a series of events, we are in big trouble - any (serious) refactoring of the aggregate structure becomes close to impossible. The reason for this trouble is that we have to make a decision in the design phase for which we cannot be lenient. We are basically married to this decision forever. Due to the aforementioned reasons (and many others), people struggle with the Aggregate pattern. Some even say it is unnecessary, we are one of those. Lets see whether we can model our business constraints without aggregates. Could we be more relaxed when consistency is in question? Join us to discover how! <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/theaggregateisdeadlonglivetheaggregate-springio-230529080953-42e5d6a9-thumbnail.jpg?width=120&amp;height=120&amp;fit=bounds" /><br> https://2023.springio.net/sessions/the-aggregate-is-dead-long-live-the-aggregate/ SARA PELLEGRINI - AXONIQ MILAN SAVIC - AXONIQ DDDs definition of Aggregate may seem somewhat confusing - An aggregate is a cluster of associated objects that we treat as a unit for the purpose of data changes. Okay, lets try to clarify - You should consider your aggregate as a unit of consistency in your Domain.. That doesnt help either. As a matter of fact, while modeling our systems, we tend to group together events related to the same domain concept; we tend to define groups based on the nouns we find inside our events name: saying this is our aggregate!. According to the aggregate definition, we should instead ignore these nouns, and put together the data that change together. Easier said than done: in the modeling phase it is easy to make mistakes trying to identify the boundaries of our aggregates based on this rule. If we opt for saving the state of our aggregate as a series of events, we are in big trouble - any (serious) refactoring of the aggregate structure becomes close to impossible. The reason for this trouble is that we have to make a decision in the design phase for which we cannot be lenient. We are basically married to this decision forever. Due to the aforementioned reasons (and many others), people struggle with the Aggregate pattern. Some even say it is unnecessary, we are one of those. Lets see whether we can model our business constraints without aggregates. Could we be more relaxed when consistency is in question? Join us to discover how!
The aggregate is dead! Long live the aggregate! - SpringIO.pdf from Sara Pellegrini
]]> 234 0 https://cdn.slidesharecdn.com/ss_thumbnails/theaggregateisdeadlonglivetheaggregate-springio-230529080953-42e5d6a9-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post http://activitystrea.ms/schema/1.0/posted 0 Kill Aggregate /slideshow/kill-aggregate/257807451 killaggregate-avanscoperta-230512213833-c2dcad53
Presented by Sara Pellegrini https://sara.event-thinking.io/ Hosted by Avanscoperta https://www.avanscoperta.it/en Streaming Video https://www.youtube.com/watch?v=DhhxKoOpJe0 L'aggregato ha sempre rappresentato per me uno degli elementi pi湛 controversi e deboli della teoria del DDD. La sua definizione risulta a mio parere estremamente vaga: "L'aggregato 辿 un cluster di oggetti associati che devono essere trattati come una sola unit al fine di modificare i dati." Tentiamo di chiarire meglio il concetto: "L'aggregato costituisce l'unit叩 di consistenza del tuo dominio" Le cose non migliorano di molto... Durante la mia attivit di consulenza, ho potuto verificare che la piena comprensione del concetto di aggregato rimane ostica per molti. E' facile commettere errori in fase di modellazione ai quali sar叩 molto complesso porre rimedio in fasi pi炭 avanzate dello sviluppo. Come conseguenza, una certa percentuale di sviluppatori si convince che l'intera architettura sia eccessivamente difficile e complicata. Il mio obiettivo 辿 proprio quello di mostrarvi una via alternativa, nella quale l'aggregato non esiste. ]]>
Presented by Sara Pellegrini https://sara.event-thinking.io/ Hosted by Avanscoperta https://www.avanscoperta.it/en Streaming Video https://www.youtube.com/watch?v=DhhxKoOpJe0 L'aggregato ha sempre rappresentato per me uno degli elementi pi湛 controversi e deboli della teoria del DDD. La sua definizione risulta a mio parere estremamente vaga: "L'aggregato 辿 un cluster di oggetti associati che devono essere trattati come una sola unit al fine di modificare i dati." Tentiamo di chiarire meglio il concetto: "L'aggregato costituisce l'unit叩 di consistenza del tuo dominio" Le cose non migliorano di molto... Durante la mia attivit di consulenza, ho potuto verificare che la piena comprensione del concetto di aggregato rimane ostica per molti. E' facile commettere errori in fase di modellazione ai quali sar叩 molto complesso porre rimedio in fasi pi炭 avanzate dello sviluppo. Come conseguenza, una certa percentuale di sviluppatori si convince che l'intera architettura sia eccessivamente difficile e complicata. Il mio obiettivo 辿 proprio quello di mostrarvi una via alternativa, nella quale l'aggregato non esiste. ]]> Fri, 12 May 2023 21:38:33 GMT /slideshow/kill-aggregate/257807451 saratry@slideshare.net(saratry) Kill Aggregate saratry Presented by Sara Pellegrini https://sara.event-thinking.io/ Hosted by Avanscoperta https://www.avanscoperta.it/en Streaming Video https://www.youtube.com/watch?v=DhhxKoOpJe0 L'aggregato ha sempre rappresentato per me uno degli elementi pi湛 controversi e deboli della teoria del DDD. La sua definizione risulta a mio parere estremamente vaga: "L'aggregato 辿 un cluster di oggetti associati che devono essere trattati come una sola unit al fine di modificare i dati." Tentiamo di chiarire meglio il concetto: "L'aggregato costituisce l'unit叩 di consistenza del tuo dominio" Le cose non migliorano di molto... Durante la mia attivit di consulenza, ho potuto verificare che la piena comprensione del concetto di aggregato rimane ostica per molti. E' facile commettere errori in fase di modellazione ai quali sar叩 molto complesso porre rimedio in fasi pi炭 avanzate dello sviluppo. Come conseguenza, una certa percentuale di sviluppatori si convince che l'intera architettura sia eccessivamente difficile e complicata. Il mio obiettivo 辿 proprio quello di mostrarvi una via alternativa, nella quale l'aggregato non esiste. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/killaggregate-avanscoperta-230512213833-c2dcad53-thumbnail.jpg?width=120&amp;height=120&amp;fit=bounds" /><br> Presented by Sara Pellegrini https://sara.event-thinking.io/ Hosted by Avanscoperta https://www.avanscoperta.it/en Streaming Video https://www.youtube.com/watch?v=DhhxKoOpJe0 L&#39;aggregato ha sempre rappresentato per me uno degli elementi pi湛 controversi e deboli della teoria del DDD. La sua definizione risulta a mio parere estremamente vaga: &quot;L&#39;aggregato 辿 un cluster di oggetti associati che devono essere trattati come una sola unit al fine di modificare i dati.&quot; Tentiamo di chiarire meglio il concetto: &quot;L&#39;aggregato costituisce l&#39;unit叩 di consistenza del tuo dominio&quot; Le cose non migliorano di molto... Durante la mia attivit di consulenza, ho potuto verificare che la piena comprensione del concetto di aggregato rimane ostica per molti. E&#39; facile commettere errori in fase di modellazione ai quali sar叩 molto complesso porre rimedio in fasi pi炭 avanzate dello sviluppo. Come conseguenza, una certa percentuale di sviluppatori si convince che l&#39;intera architettura sia eccessivamente difficile e complicata. Il mio obiettivo 辿 proprio quello di mostrarvi una via alternativa, nella quale l&#39;aggregato non esiste.
Kill Aggregate from Sara Pellegrini
]]> 173 0 https://cdn.slidesharecdn.com/ss_thumbnails/killaggregate-avanscoperta-230512213833-c2dcad53-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post http://activitystrea.ms/schema/1.0/posted 0 Axon Framework - Dal monolite ai microservizi con un approccio evolutivo /slideshow/axon-framework-dal-monolite-ai-microservizi-con-un-approccio-evolutivo/100390254 dalmonoliteaimicroserviziconunapproccioevolutivo-final-180604081625
Un viaggio attraverso CQRS, Domain Driven Design e Event Sourcing, per comprendere, partendo dalle basi, come Axon Framework possa rappresentare l'alleato ideale nell'implementazione di applicazioni a microservizi con un approccio evolutivo.]]>
Un viaggio attraverso CQRS, Domain Driven Design e Event Sourcing, per comprendere, partendo dalle basi, come Axon Framework possa rappresentare l'alleato ideale nell'implementazione di applicazioni a microservizi con un approccio evolutivo.]]> Mon, 04 Jun 2018 08:16:25 GMT /slideshow/axon-framework-dal-monolite-ai-microservizi-con-un-approccio-evolutivo/100390254 saratry@slideshare.net(saratry) Axon Framework - Dal monolite ai microservizi con un approccio evolutivo saratry Un viaggio attraverso CQRS, Domain Driven Design e Event Sourcing, per comprendere, partendo dalle basi, come Axon Framework possa rappresentare l'alleato ideale nell'implementazione di applicazioni a microservizi con un approccio evolutivo. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/dalmonoliteaimicroserviziconunapproccioevolutivo-final-180604081625-thumbnail.jpg?width=120&amp;height=120&amp;fit=bounds" /><br> Un viaggio attraverso CQRS, Domain Driven Design e Event Sourcing, per comprendere, partendo dalle basi, come Axon Framework possa rappresentare l&#39;alleato ideale nell&#39;implementazione di applicazioni a microservizi con un approccio evolutivo.
Axon Framework - Dal monolite ai microservizi con un approccio evolutivo from Sara Pellegrini
]]> 432 34 https://cdn.slidesharecdn.com/ss_thumbnails/dalmonoliteaimicroserviziconunapproccioevolutivo-final-180604081625-thumbnail.jpg?width=120&height=120&fit=bounds presentation White http://activitystrea.ms/schema/1.0/post http://activitystrea.ms/schema/1.0/posted 0 https://cdn.slidesharecdn.com/profile-photo-saratry-48x48.jpg?cb=1695914344 Sara Pellegrini is an enthusiastic and proactive IT professional who specializes in distributed architectures. Able to see things from a different perspective, with a broad approach to software development, from coding skills to high-level architectural view. Since 2018 she collaborates with AxonIQ, helping people implement reliable event-driven distributed systems. sara.event-thinking.io/ https://cdn.slidesharecdn.com/ss_thumbnails/theaggregateisdeadlonglivetheaggregate-springio-230529080953-42e5d6a9-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/the-aggregate-is-dead-long-live-the-aggregate-springiopdf/258098161 The aggregate is dead!... https://cdn.slidesharecdn.com/ss_thumbnails/killaggregate-avanscoperta-230512213833-c2dcad53-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/kill-aggregate/257807451 Kill Aggregate https://cdn.slidesharecdn.com/ss_thumbnails/dalmonoliteaimicroserviziconunapproccioevolutivo-final-180604081625-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/axon-framework-dal-monolite-ai-microservizi-con-un-approccio-evolutivo/100390254 Axon Framework - Dal m...