-
Notifications
You must be signed in to change notification settings - Fork 3
/
path---docs-tips-and-tricks-3d7f7d58c20c62afa56e.js
2 lines (2 loc) · 25.6 KB
/
path---docs-tips-and-tricks-3d7f7d58c20c62afa56e.js
1
2
webpackJsonp([40985414794637],{427:function(e,t){e.exports={data:{allPostTitles:{edges:[{node:{frontmatter:{title:"Getting Started",lesson:1,category:"akkatecture",chapter:1,type:"docs"},fields:{slug:"/getting-started"}}},{node:{frontmatter:{title:"Primitives",lesson:1,category:"akkatecture",chapter:2,type:"docs"},fields:{slug:"/primitives"}}},{node:{frontmatter:{title:"Walkthrough Introduction",lesson:1,category:"akkatecture",chapter:3,type:"docs"},fields:{slug:"/walkthrough-introduction"}}},{node:{frontmatter:{title:"Sagas",lesson:1,category:"akkatecture",chapter:4,type:"docs"},fields:{slug:"/sagas"}}},{node:{frontmatter:{title:"Tips and Tricks",lesson:1,category:"akkatecture",chapter:5,type:"docs"},fields:{slug:"/tips-and-tricks"}}},{node:{frontmatter:{title:"Aggregates",lesson:2,category:"akkatecture",chapter:2,type:"docs"},fields:{slug:"/aggregates"}}},{node:{frontmatter:{title:"Your First Aggregate",lesson:2,category:"akkatecture",chapter:3,type:"docs"},fields:{slug:"/your-first-aggregate"}}},{node:{frontmatter:{title:"Snapshotting",lesson:2,category:"akkatecture",chapter:4,type:"docs"},fields:{slug:"/snapshotting"}}},{node:{frontmatter:{title:"Articles",lesson:2,category:"akkatecture",chapter:5,type:"docs"},fields:{slug:"/articles"}}},{node:{frontmatter:{title:"Events",lesson:3,category:"akkatecture",chapter:2,type:"docs"},fields:{slug:"/events"}}},{node:{frontmatter:{title:"Your First Commands",lesson:3,category:"akkatecture",chapter:3,type:"docs"},fields:{slug:"/your-first-commands"}}},{node:{frontmatter:{title:"Clustering",lesson:3,category:"akkatecture",chapter:4,type:"docs"},fields:{slug:"/clustering"}}},{node:{frontmatter:{title:"Videos",lesson:3,category:"akkatecture",chapter:5,type:"docs"},fields:{slug:"/videos"}}},{node:{frontmatter:{title:"Commands",lesson:4,category:"akkatecture",chapter:2,type:"docs"},fields:{slug:"/commands"}}},{node:{frontmatter:{title:"Your First Events",lesson:4,category:"akkatecture",chapter:3,type:"docs"},fields:{slug:"/your-first-events"}}},{node:{frontmatter:{title:"Production Readiness",lesson:4,category:"akkatecture",chapter:4,type:"docs"},fields:{slug:"/production-readiness"}}},{node:{frontmatter:{title:"Specifications",lesson:5,category:"akkatecture",chapter:2,type:"docs"},fields:{slug:"/specifications"}}},{node:{frontmatter:{title:"Your First Specifications",lesson:5,category:"akkatecture",chapter:3,type:"docs"},fields:{slug:"/your-first-specifications"}}},{node:{frontmatter:{title:"Event Upgrading",lesson:5,category:"akkatecture",chapter:4,type:"docs"},fields:{slug:"/event-upgrading"}}},{node:{frontmatter:{title:"Subscribers",lesson:6,category:"akkatecture",chapter:2,type:"docs"},fields:{slug:"/subscribers"}}},{node:{frontmatter:{title:"Your First Aggregate Test",lesson:6,category:"akkatecture",chapter:3,type:"docs"},fields:{slug:"/your-first-aggregate-test"}}},{node:{frontmatter:{title:"Testing Aggregates",lesson:6,category:"akkatecture",chapter:4,type:"docs"},fields:{slug:"/testing-aggregates"}}},{node:{frontmatter:{title:"Scheduled Jobs",lesson:7,category:"akkatecture",chapter:2,type:"docs"},fields:{slug:"/scheduled-jobs"}}},{node:{frontmatter:{title:"Your First Aggregate Saga",lesson:7,category:"akkatecture",chapter:3,type:"docs"},fields:{slug:"/your-first-aggregate-saga"}}},{node:{frontmatter:{title:"Akka",lesson:8,category:"akkatecture",chapter:2,type:"docs"},fields:{slug:"/akka"}}},{node:{frontmatter:{title:"Your First Subscribers",lesson:8,category:"akkatecture",chapter:3,type:"docs"},fields:{slug:"/your-first-subscribers"}}},{node:{frontmatter:{title:"Configuration",lesson:9,category:"akkatecture",chapter:2,type:"docs"},fields:{slug:"/configuration"}}},{node:{frontmatter:{title:"Your First Projections",lesson:9,category:"akkatecture",chapter:3,type:"docs"},fields:{slug:"/your-first-projections"}}},{node:{frontmatter:{title:"Walkthrough Ending",lesson:10,category:"akkatecture",chapter:3,type:"docs"},fields:{slug:"/walkthrough-ending"}}}]},postBySlug:{html:'<p>Whenever creating an application that uses cqrs and event sourcing there are several things you need to keep in mind to minimize the potential culmination bugs, and headaches to occur.</p>\n<h2 id="events"><a href="#events" aria-hidden="true" class="anchor"><svg aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Events</h2>\n<p>Make sure that when your aggregate events are JSON serialized. Since these aggregate events may be used by external systems in the future of your application, they need to be as bare bones as possible with the least amount of noise to the data possible. Make sure that the events have:</p>\n<ul>\n<li>No type information</li>\n<li>No runtime information</li>\n</ul>\n<p>It is ok to have this information in the event metadata for analytics or other concerns however they serve no business sense (normally) to be part of the events data payload.</p>\n<p>Here\'s an example of good clean aggregate event JSON produced from a create user\nevent.</p>\n<div class="gatsby-highlight">\n <pre class="language-json"><code class="language-json">//AggregateEvent\n<span class="token punctuation">{</span>\n <span class="token property">"Username"</span><span class="token operator">:</span> <span class="token string">"root"</span><span class="token punctuation">,</span>\n <span class="token property">"PasswordHash"</span><span class="token operator">:</span> <span class="token string">"1234567890ABCDEF"</span><span class="token punctuation">,</span>\n <span class="token property">"EMail"</span><span class="token operator">:</span> <span class="token string">"root@example.org"</span><span class="token punctuation">,</span>\n<span class="token punctuation">}</span></code></pre>\n </div>\n<p><strong>Keep Aggregate Events As Slim As Possible</strong></p>\n<p>A good rule of thumb is to minimize the amount of noisey data that can exist in the aggregate event. If your state event applying method uses all of the event member variables on invokation, then you have a good event. adding bloat and extra data to events waters down how true the events are. Events embody \'facts which happened\' in your domain. If you add unessacary \'facts\' that dont pertain to that event in your event model, then that event becomes less \'fact-y\'.</p>\n<p><strong>Functional Apply Methods</strong></p>\n<p>Your apply methods should be functional over your aggregate\'s state. Meaning, the application of an aggregate event <code class="language-text">eₓ</code> over the aggregate state <code class="language-text">S</code> at sequence number <code class="language-text">n</code> should be <code class="language-text">Sₙ₊₁ = apply Sₙ eₓ</code>, for any given or fixed <code class="language-text">n</code> this function should always return the same <code class="language-text">Sₙ₊₁</code>.</p>\n<p><strong>Keep Old Event Types</strong></p>\n<p>Keep in mind, that you need to keep the event types in your code for as long as these events are in the event source, which in most cases are <em>forever</em> as storage is cheap and information, i.e., your domain events, are expensive. Distinguish between old event types and broken event types with high scrutiny as these are the fundamental building blocks of your domain.</p>\n<p>However, you should still clean your code, have a look at how you can\n<a href="/docs/event-upgrading">upgrade and version your events </a> for details on\nhow Akkatecture suggests to you in how to solve this.</p>\n<p><strong>Honour Transactional Boundaries</strong></p>\n<p>Sometimes you may have a command that has the potential to cause multiple events to be applied and emitted to the aggregate. Which means you will have to resort to using multiple <code class="language-text">Emit(...)</code> methods procedurally. The problem with using multiple <code class="language-text">Emit(...)</code>s for the same command context is that out of the <code class="language-text">N</code> events emitted in the same context one of them may fail, which will cause the rest of the subsequent events to fail as well. This can put your aggregate root into an intermediate and unrecognisable state. To get around this, use the <code class="language-text">EmitAll(...)</code> api from the aggregate root to ensure that the string of events can be stored as one transaction.</p>\n<blockquote>\n<p>Depending on your event journal you may not have these transaction guarantees, consult your chosen <code class="language-text">Akka.Persistence</code> plugin\'s documentation to discern how this behaviour works.</p>\n</blockquote>\n<h2 id="unit-testing"><a href="#unit-testing" aria-hidden="true" class="anchor"><svg aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Unit Testing</h2>\n<p>Unit test your aggregates and sagas in isolation from one another. By using black box style testing you can follow this approach.</p>\n<p><strong>Aggregate Testing</strong></p>\n<ul>\n<li>Arrange - setup the aggregate actor, listen to the aggregate actors possible emitted events.</li>\n<li>Act - send the aggregate actor a command.</li>\n<li>Assert - check to see if the aggregate actor emits the domain event as desired.</li>\n</ul>\n<p> <strong>Saga Testing</strong></p>\n<ul>\n<li>Arrange - setup the saga actor, listen to the saga actors issued commands by mocking its actor reference to a test probe actor</li>\n<li>Act - send the saga actor a domain event.</li>\n<li>Assert - check to see if the saga actor tells the probe actor the desired command.</li>\n</ul>\n<p>It will be most advantageous to learn akka.net\'s <a href="http://getakka.net/articles/actors/testing-actor-systems.html">test kit</a></p>\n<h2 id="make-your-domain-expressive"><a href="#make-your-domain-expressive" aria-hidden="true" class="anchor"><svg aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Make Your Domain Expressive</h2>\n<p>Your domain code is your business model codified. Make sure that you apply the principle of a ubiquitous language to your domain by being explicit but terse in your naming conventions, this leads to a far more enjoyable developer expirience for those who share the code base. With the fall in popularity of UML diagrams and other forms of non-code business domain models, code written in a ddd way <strong>is</strong> your business domain model.</p>\n<h2 id="plan-for-uncertainty--inconsistency-in-clustered-scenarios"><a href="#plan-for-uncertainty--inconsistency-in-clustered-scenarios" aria-hidden="true" class="anchor"><svg aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Plan For Uncertainty & Inconsistency In Clustered Scenarios</h2>\n<p>In an asynchronous message passing system, there are always trade offs to be made when it comes to messaging guarantees in a distributed environment. Especially when the distributed environment is partitioned by a network. Akka\'s default message delivery semantics can result in a really high throughput and scalable system, however sometimes at most once message delivery semantics may not be ideal for your use case. It is also worthy to note that message ordering in akka might need to be taken into consideration when designing your actor system.</p>\n<h3 id="message-sending-guarantees"><a href="#message-sending-guarantees" aria-hidden="true" class="anchor"><svg aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Message Sending Guarantees</h3>\n<p>For local scenarios, message sending is <a href="https://getakka.net/articles/concepts/message-delivery-reliability.html#reliability-of-local-message-sends">mostly guaranteed</a> in akka.net. However since akka.net, and by extension, Akkatecture\'s default messaging policy being <a href="https://developer.lightbend.com/blog/2017-08-10-atotm-akka-messaging-part-1/index.html">at most once message delivery delivery</a>, in a networked environment message sending guarantees become more important to the integrity of your application. In at most once delivery, an attempt is made by actors to send a message to the receiver. Any number of things may happen that prevent the successful delivery of an asynchronous message, including, but not limited to packet loss over a network transport.</p>\n<h3 id="message-receiving-order"><a href="#message-receiving-order" aria-hidden="true" class="anchor"><svg aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Message Receiving Order</h3>\n<p>Another general rule that is message ordering can only be guaranteed on a sender-receiver pair level.</p>\n<p>The ordering guarantee is illustrated in the following:</p>\n<p>Actor <code class="language-text">A1</code> sends messages <code class="language-text">M1</code> <code class="language-text">M2</code> <code class="language-text">M3</code> to <code class="language-text">A2</code>.\nActor <code class="language-text">A3</code> sends messages <code class="language-text">M4</code> <code class="language-text">M5</code> <code class="language-text">M6</code> to <code class="language-text">A2</code>.</p>\n<p>If <code class="language-text">M1</code> is delivered it must be delivered before <code class="language-text">M2</code> and <code class="language-text">M3</code>.\nIf <code class="language-text">M2</code> is delivered it must be delivered before <code class="language-text">M3</code>.\nIf <code class="language-text">M4</code> is delivered it must be delivered before <code class="language-text">M5</code> and <code class="language-text">M6</code>.\nIf <code class="language-text">M5</code> is delivered it must be delivered before <code class="language-text">M6</code>.</p>\n<p><code class="language-text">A2</code> can see messages from <code class="language-text">A1</code> interleaved with messages from <code class="language-text">A3</code>.</p>\n<blockquote>\n<p>An example of message ordering as seen from <code class="language-text">A2</code>\'s perspective might be <code class="language-text">M4</code> <code class="language-text">M5</code> <code class="language-text">M1</code> <code class="language-text">M2</code> <code class="language-text">M3</code> <code class="language-text">M6</code>.</p>\n</blockquote>\n<h2 id="actor-behaviours"><a href="#actor-behaviours" aria-hidden="true" class="anchor"><svg aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Actor Behaviours</h2>\n<p>To test and manage actors that do not use akka.net\'s <code class="language-text">Become()</code> methods can become cumbersome. Akkatecture comes with a <a href="/docs/specifications">specification pattern implementation</a> that will give you the option to do some rich, expressive, domain validation within the actors. Specifications are also highly testable. Feel free to use this at your pleasure.</p>\n<h2 id="validate-inputs"><a href="#validate-inputs" aria-hidden="true" class="anchor"><svg aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Validate Inputs</h2>\n<p>Validating inputs in CQRS that typically means validate your commands and queries. Do as much <em>static</em> or <em>shallow</em> validation as possible, <code class="language-text">null</code> checks, and checks for <code class="language-text">default(T)</code> such things are highly recommended where applicable.</p>\n<p><strong>Aggregate Event Members Should Be Primitive</strong></p>\n<p>This is to protect against invariants of domain models, Make sure that your event in its serialized form can be deserialized to any primitive type. Using complex (class) a type as a member in your aggregate event definition can be problematic, if the complex type changes by mistake or otherwise, it can render your aggregate event useless.</p>\n<p>For example consider this case:</p>\n<div class="gatsby-highlight">\n <pre class="language-csharp"><code class="language-csharp"><span class="token keyword">public</span> <span class="token keyword">class</span> <span class="token class-name">GameEndedEvent</span> <span class="token punctuation">:</span> <span class="token class-name">AggregateEvent</span><span class="token operator"><</span>GameAggregate<span class="token punctuation">,</span> GameAggregateId<span class="token operator">></span>\n<span class="token punctuation">{</span>\n <span class="token comment">//ZonedDateTime is a NodaTime type from a NuGet package</span>\n <span class="token keyword">public</span> <span class="token class-name">ZonedDateTime</span> TimeEnded <span class="token punctuation">{</span> <span class="token keyword">get</span><span class="token punctuation">;</span> <span class="token punctuation">}</span>\n <span class="token comment">//Team is an Entity<TeamId> from this example\'s domain project</span>\n <span class="token keyword">public</span> <span class="token class-name">Team</span> WinningTeam <span class="token punctuation">{</span> <span class="token keyword">get</span><span class="token punctuation">;</span> <span class="token punctuation">}</span>\n\n <span class="token keyword">public</span> <span class="token function">GameEndedEvent</span><span class="token punctuation">(</span>\n <span class="token class-name">ZonedDateTime</span> timeEnded<span class="token punctuation">,</span>\n <span class="token class-name">Team</span> winningTeam<span class="token punctuation">)</span>\n <span class="token punctuation">{</span>\n TimeEnded <span class="token operator">=</span> timeEnded<span class="token punctuation">;</span>\n WinningTeam <span class="token operator">=</span> winningTeam<span class="token punctuation">;</span>\n <span class="token punctuation">}</span>\n<span class="token punctuation">}</span></code></pre>\n </div>\n<p>In the <code class="language-text">GameEndedEvent</code> class definition, there are two members called <code class="language-text">TimeEnded</code> and <code class="language-text">WinningTeam</code>, with the types <code class="language-text">ZonedDateTime</code> (from <a href="https://nodatime.org/">NodaTime</a>) and <code class="language-text">Team</code> respectively. The issue with an event like this is that unless we freeze the version of the NodaTime package at the point of this events instantiation, we cant guarantee that this event will be able to be used in the future due to NodaTime making their own independant changes to the <code class="language-text">ZonedDateTime</code> type. The issue with the <code class="language-text">Team</code> entity existing in the aggregate event itself can also be problematic since the <code class="language-text">Team</code> entity can evolve within your codebase independantly of the GameEndedEvent. In short, be very careful when adding types to your aggregate event that may evolve. BCL types and primitive types are safe bets because they evolve quite slow in comparison to other types from libraries or your own domain code. See <a href="https://buildplease.com/pages/vos-in-events/">this</a> post which might persuade you even more.</p>\n<p>an example of a better <code class="language-text">GameEndedEvent</code> might be:</p>\n<div class="gatsby-highlight">\n <pre class="language-csharp"><code class="language-csharp"><span class="token keyword">public</span> <span class="token keyword">class</span> <span class="token class-name">GameEndedEvent</span> <span class="token punctuation">:</span> <span class="token class-name">AggregateEvent</span><span class="token operator"><</span>GameAggregate<span class="token punctuation">,</span> GameAggregateId<span class="token operator">></span>\n<span class="token punctuation">{</span>\n <span class="token keyword">public</span> <span class="token class-name">DateTime</span> TimeEnded <span class="token punctuation">{</span> <span class="token keyword">get</span><span class="token punctuation">;</span> <span class="token punctuation">}</span>\n <span class="token keyword">public</span> <span class="token class-name">Guid</span> WinningTeamId <span class="token punctuation">{</span> <span class="token keyword">get</span><span class="token punctuation">;</span> <span class="token punctuation">}</span> \n <span class="token keyword">public</span> <span class="token keyword">string</span> WinningTeamName <span class="token punctuation">{</span> <span class="token keyword">get</span><span class="token punctuation">;</span> <span class="token punctuation">}</span>\n <span class="token keyword">public</span> IReadOnlyList<span class="token operator"><</span>Guid<span class="token operator">></span> WinningTeamMemberIds <span class="token punctuation">{</span><span class="token keyword">get</span><span class="token punctuation">;</span><span class="token punctuation">}</span> \n\n <span class="token keyword">public</span> <span class="token function">GameEndedEvent</span><span class="token punctuation">(</span>\n <span class="token class-name">DateTime</span> timeEnded<span class="token punctuation">,</span>\n <span class="token class-name">Guid</span> winningTeamId<span class="token punctuation">,</span>\n <span class="token keyword">string</span> winningTeamName<span class="token punctuation">,</span>\n IReadOnlyList<span class="token operator"><</span>Guid<span class="token operator">></span> winningTeamMemberIds<span class="token punctuation">)</span>\n <span class="token punctuation">{</span>\n TimeEnded <span class="token operator">=</span> timeEnded<span class="token punctuation">;</span>\n WinningTeamId <span class="token operator">=</span> winningTeamId<span class="token punctuation">;</span>\n WinningTeamName <span class="token operator">=</span> winningTeamName<span class="token punctuation">;</span>\n WinningTeamMemberIds <span class="token operator">=</span> winningTeamMemberIds\n <span class="token punctuation">}</span>\n<span class="token punctuation">}</span></code></pre>\n </div>\n<p>In the event model above, the members are defined by BCL types that are "quite invariant", however if you want to be super safe, rather use primitive types or arrays of those primitive types or maps of those primitive types.</p>\n<blockquote>\n<p>Caveats or points of contention of this rule may include simple value objects like single value objects in Akkatecture that get serialized into a single primitive type. As long as you do not change the underlying primitive type of the <code class="language-text">SingleValueObject</code> you will be fine.</p>\n</blockquote>',timeToRead:8,excerpt:"Whenever creating an application that uses cqrs and event sourcing there are several things you need to keep in mind to minimize the…",frontmatter:{title:"Tips and Tricks",cover:"https://unsplash.it/400/300/?random?BoldMage",date:"01/07/2018",category:"akkatecture",tags:["further-self-study","akkatecture","csharp","dotnet"]},fields:{slug:"/tips-and-tricks"}}},pathContext:{slug:"/tips-and-tricks",category:"akkatecture"}}}});
//# sourceMappingURL=path---docs-tips-and-tricks-3d7f7d58c20c62afa56e.js.map