-
Notifications
You must be signed in to change notification settings - Fork 8
/
atom.xml
553 lines (366 loc) · 49.7 KB
/
atom.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title>Project “a CQRS Journey”</title>
<link href="http://cqrsjourney.github.com/atom.xml" rel="self"/>
<link href="http://cqrsjourney.github.com/"/>
<updated>2012-08-07T12:05:48-07:00</updated>
<id>http://cqrsjourney.github.com/</id>
<author>
<name>Microsoft patterns & practices</name>
<email>cqrsdv@live.com</email>
</author>
<entry>
<title>The first Journey is complete</title>
<link href="http://cqrsjourney.github.com/blog/2012/07/28/The-Journey-is-complete/"/>
<updated>2012-07-28T09:00:00-07:00</updated>
<id>http://cqrsjourney.github.com/blog/2012/07/28/The-Journey-is-complete</id>
<content type="html"><p>We have now reached the end of this journey. See the official announcement with the full list of acknowledgements <a href="http://aka.ms/cqrsrelease">here</a>.
You can check out the guide and the corresponding reference implementation at <a href="http://aka.ms/cqrs">http://aka.ms/cqrs</a>.</p>
<p><a href="http://aka.ms/cqrs"><img src="http://cqrsjourney.github.com/images/posts/Map_cqrs_journey_small.png" alt="CQRS Journey Map" border="0" /></a></p>
<p>We also welcome your feedback and stories with your own experiences. Check out the section of the guide called <em>Tales from the Trenches</em> which includes mini-cases studies of other teams implementing the CQRS and ES patterns in the real world. Some of them validate our findings, others provide different perspectives. Take our project for a spin, explore our findings and those of others, and tell your story! Email us at
<strong>cqrsjourney</strong> at <strong>microsoft</strong> dot <strong>com</strong>.</p>
<p>There&#8217;s still a lot to explore. We would like to encourage the community to improve and extend our implementation of the Contoso Conference Management System. The github <a href="https://github.com/mspnp/cqrs-journey-code">code repo</a> remains open and we&#8217;ll continue to review any and all of your pull requests.</p>
<p>Once again, your feedback is very important. Based on it, we may or may not decide to embark on the second journey in the future. For now, we remain enthused!</p>
</content>
</entry>
<entry>
<title>V3 Final Release</title>
<link href="http://cqrsjourney.github.com/blog/2012/07/19/V3-Final-Release/"/>
<updated>2012-07-19T10:31:00-07:00</updated>
<id>http://cqrsjourney.github.com/blog/2012/07/19/V3-Final-Release</id>
<content type="html"><p>This is our <a href="http://cqrsjourney.github.com/blog/2012/05/30/plans-for-v3/">third (and final for this project) pseudo-production release</a> of the Contoso Conference Management System. The plan was to focus on hardening and optimizing the system, and to see if we could perform the no-downtime upgrade that we didn&#8217;t manage to achieve in the previous update from <a href="http://cqrsjourney.github.com/blog/2012/05/21/V2-Pseudo-Production-Release-is-out/">V1 to V2</a>.</p>
<p>There were no new business features implemented in this release, but we did make significant changes to the code as part of our efforts to harden and optimize the system.</p>
<p><a href="http://en.wikipedia.org/wiki/File:3_tourist_helping_artist_blacksmith_in_finland.JPG"><img src="http://cqrsjourney.github.com/images/posts/hardening.jpg" alt="Original image under the Creative Commons Attribution-Share Alike 3.0 Unported license" border="0" /></a></p>
<h2>Hardening the system</h2>
<p>As part of this release, the team revisited the <strong>RegistrationProcessManager</strong> to ensure its resilience to a wide range of potential failure conditions. These changes fall into two categories:</p>
<ul>
<li>Resilience in the face of duplicate events: the system must guarantee idempotent behavior, so that if for any reason it tries to process an individual event more than once, then this does not result in inconsistencies.</li>
<li>Robustness when sending commands: the team implemented a pseudo-transaction to provide guarantees that the system always sends any outstanding commands from the <strong>RegistrationProcessManager</strong> whenever it saves the process manager&#8217;s state. A pseudo-transaction is necessary because it is neither advisable nor possible to enlist the Windows Azure Service Bus and a SQL Database table together in a distributed transaction.</li>
</ul>
<h2>No-downtime migration</h2>
<p>The team implemented a no-downtime migration strategy to get from V2 to V3 and successfully performed this migration on the live system deployed to Windows Azure. To help with this process, we created an ad-hoc processor that keeps the V2 read-models up to date during the migration process. This was necessary because we replace the V2 processor with the V3 processor before we switch to the new V3 front-end.</p>
<h2>Optimizing the system</h2>
<p>The optimizations added by the team were optimizations to improve both the performance and the scalability of the system. These optimizations took the majority of the team&#8217;s effort in this release. As is often the case with performance tuning, addressing one bottleneck frequently revealed another elsewhere in the system. The optimizations occurred in two places; first, in the UI flow, and second, in the infrastructure.</p>
<h3>UI optimizations</h3>
<p>The optimizations implemented in the UI flow were designed to streamline the behind-the-scenes processes that take place between the time that a registrant selects seats for a conference and the time the registrant pays for those seats. The changes mean that the user is far less likely to have to wait at any point in this process, but still ensuring that the system checks that the requested seats are available before accepting payment. It does this in two ways. First, when there are plenty of seats available for a conference, the system assumes that the reservation will succeed and so performs the reservation asynchronously while the registrant is completing other screens in the UI and before the regenerating gets to the payment stage. Secondly, we reorganized the <strong>Order</strong> entity to perform the totals calculation as one of its first tasks instead of one of its last tasks, making the information available in a read model much sooner that was previously the case.</p>
<h3>Infrastructure optimizations</h3>
<p>These were the most effective optimizations, but took the longest time to identify and implement. The optimizations included:</p>
<ul>
<li>Handling the majority of I/O operations asynchronously. This is recommended practice, but makes the code much harder to read especially when combined with transient fault handling logic.</li>
<li>Processing some commands in-process instead of pushing them through the service bus. In some cases it is possible to handle commands in the same process where they are sent, and this therefore reduces the number of messages we are sending through the service bus and reduces the latency in delivering those command messages.</li>
<li>Implementing snapshots in the event sourcing sub-system. This is a common optimization to event sourcing, and we implemented this in memory using the Memento pattern.</li>
<li>Caching read-model data. Again, this is a common optimization, but this raises the question of how frequently the cache is updated.</li>
<li>Tuning the Windows Azure Service Bus by using features such as filters and by implementing parallel publishing, parallel sessions, partitioned topics, and more. For proven perf optimization practices, see this <a href="http://aka.ms/SBperf">guide</a>.</li>
<li>Using sequential GUIDs to optimize insert behavior into Windows Azure SQL Database tables.</li>
</ul>
<p>For full details of these optimizations and more, take a look at Chapter 7, &#8221;<a href="https://github.com/mspnp/cqrs-journey-doc/blob/master/Journey_07_V3Release.markdown">Adding Resilience and Optimizing Performance</a>,&#8221; in the journey guide. This chapter also identifies some of the additional optimizations we would like to perform given time.</p>
<p>You can read about the V3 release in detail <a href="https://github.com/mspnp/cqrs-journey-doc/blob/master/Journey_07_V3Release.markdown">here</a>, and about all our lessons learned from the project <a href="https://github.com/mspnp/cqrs-journey-doc/blob/master/Journey_40_Conclusions.markdown">here</a>.
The code base corresponding to this release is <a href="https://github.com/mspnp/cqrs-journey-code/tags">available</a> under the <em>V3-pseudo-prod</em> tag. You can also see the list of <a href="https://github.com/mspnp/cqrs-journey-code/issues?milestone=6&amp;state=closed">implemented stories</a>.</p>
<p>You can read about the previous <a href="http://cqrsjourney.github.com/blog/2012/05/21/V2-Pseudo-Production-Release-is-out/">V2 release</a> and about the previous <a href="http://cqrsjourney.github.com/blog/2012/05/08/Announcing-V1-Pseudo-Production-Release/">V1 release</a>.</p>
<p>And of course, you can access the system with all prior data migrated:
<a href="http://cqrsjourney-conference.cloudapp.net" alt="CQRS Journey : Conference Management System"><img src="http://cqrsjourney.github.com/images/posts/cqrsjourney-conference-v3.png" border="0"/></a> &nbsp; <a href="http://cqrsjourney-conference.cloudapp.net:8080" alt="CQRS Journey : Conference Management System - Admin Portal"><img src="http://cqrsjourney.github.com/images/posts/cqrsjourney-confmgmt-v3.png" border="0"/></a></p>
</content>
</entry>
<entry>
<title>Plans for V3</title>
<link href="http://cqrsjourney.github.com/blog/2012/05/30/plans-for-v3/"/>
<updated>2012-05-30T10:56:00-07:00</updated>
<id>http://cqrsjourney.github.com/blog/2012/05/30/plans-for-v3</id>
<content type="html"><p>For our third and final release of the Contoso Conference Management System in our CQRS journey, we&#8217;re planning to focus on hardening and optimizing the system. We also intend this to be a no-downtime upgrade - something that we didn&#8217;t achieve last time around.</p>
<p>You can see the the announcements for the previous two releases here <a href="http://cqrsjourney.github.com/blog/2012/05/08/Announcing-V1-Pseudo-Production-Release/">V1</a> and here <a href="http://cqrsjourney.github.com/blog/2012/05/21/V2-Pseudo-Production-Release-is-out/">V2</a>.</p>
<h2>Hardening the System</h2>
<p>The Orders and Registrations bounded context has contained the <strong>RegistrationProcess</strong> Process Manager (are what sometimes is referred as a Saga in the CQRS community) right from our V1 release. This piece of the system is responsible for coordinating the activities of the aggregates in this bounded context and the Payment bounded context by routing commands and events between them. We&#8217;ve always been aware that a failure here could have adverse consequences for the system, especially if the aggregates got out of sync with each other, or we ended up with zombie processes. We want to make sure that the system is robust in the face of these specific failure scenarios.</p>
<p>The <strong>RegistrationProcess</strong> should be able to recover from the following:</p>
<ul>
<li>Crashes or is unable to access storage after receiving an event and before it sends any commands.</li>
<li>Crashes or is unable to access storage after saving its own state but before sending the commands.</li>
<li>Fails to mark an event as processed after it has finished doing all of its work.</li>
<li>Times-out because it is expecting a timely response from any of the commands it has sent, but for some reason the recipients of those commands fail to respond.</li>
<li>Receives an unexpected event (i.e. PaymentCompleted after the order has been expired).</li>
</ul>
<h2>Optimizing the System</h2>
<p>The optimization effort will focus around the UI flow. Currently, when a Registrant is ordering and paying for seats at a conference, the UI waits for some processing to complete in the domain (such as checking for seats availability), before displaying the next page to the Registrant. We plan to streamline this process to make the UI much more responsive, while still ensuring that a Registrant doesn&#8217;t pay for seats that the system couldn&#8217;t reserve (this is a strict domain constraint).</p>
<p>You can track our progress against the <a href="https://github.com/mspnp/cqrs-journey-code/issues?milestone=6">V3 milestone</a>.</p>
<p>Feel free to provide feedback on code/guidance and <a href="http://cqrsjourney.github.com/contributors/">contribute</a>.</p>
</content>
</entry>
<entry>
<title>V2 Pseudo-Production Release is out</title>
<link href="http://cqrsjourney.github.com/blog/2012/05/21/V2-Pseudo-Production-Release-is-out/"/>
<updated>2012-05-21T11:30:00-07:00</updated>
<id>http://cqrsjourney.github.com/blog/2012/05/21/V2-Pseudo-Production-Release-is-out</id>
<content type="html"><p>This is our <a href="http://cqrsjourney.github.com/blog/2012/05/15/Plan-for-V2/">second pseudo-production release</a> of the Contoso Conference Management System. The plan was to explore the <strong>migration process</strong> to understand better how this works in a CQRS/ES implementation and to see if we could perform a no-downtime upgrade with our current infrastructure.</p>
<p>The picture below depicts a portion of our migrated read models (only some of which are actually in SQL Azure).<br/>
<img src="http://cqrsjourney.github.com/images/posts/cqrsjourney-conference-v2-migration.png" border="0"/></p>
<p>The following user stories made it into the release:</p>
<ol>
<li><p>Providing a better user experience for <strong>zero-cost orders</strong> (in V1 the registrant was still taken to the payments system even if there was nothing to pay).</p></li>
<li><p>Displaying the number of <strong>remaining seats</strong> of each seat type in the UI (since there was no read model for this in V1).</p></li>
<li><p>Applying <strong>UX designs</strong> to the <strong>Conference Creation/Management BC</strong>.</p></li>
</ol>
<p>Unfortunately, it was not possible this time to perform a no-downtime upgrade. This was due to:</p>
<ul>
<li>The fact that we weren&#8217;t storing all the integration events needed in order to regenerate some read models, nor did we have an API for querying the state of the system from an external Bounded Context. So we now have a <strong>message log</strong> for every message that goes through the service bus.</li>
<li>Because of this, we have also decided to migrate the event store infrastructure to account for the additional metadata that the message log requires, and we will use as the base for replaying events when regenerating read models (as the message log is much easier to query and is already sorted by time).</li>
</ul>
<p>Our migration resulted in ~6 min downtime.</p>
<p>Now that we have the infrastructure in place, a no-downtime upgrade seems to be an attainable goal for our V3 release.</p>
<p>In addition to the behind-the-scenes changes listed in the previous <a href="http://cqrsjourney.github.com/blog/2012/05/15/Plan-for-V2/">post</a>, the team made the following changes:</p>
<ul>
<li>As mentioned above, there is a now a message log that persists all commands and events. This grew out of the need to persist the integration events. In addition to regenerating read models from events, this is also intended to future-proof the application by capturing everything that might be of interest at some point in the future.</li>
<li>The Conference solution now includes a migration program to migrate the data to the new event store, re-create the integration events that the V1 release did not persist, and rebuild the read-models with additonal data.</li>
<li>Several bug fixes (see the <a href="https://github.com/mspnp/cqrs-journey-code/issues?labels=&amp;milestone=5&amp;page=1&amp;state=closed">backlog for V2</a> or the <a href="https://github.com/mspnp/cqrs-journey-code/commits/dev">commit history</a>)</li>
</ul>
<p>You can access the updated version of the application as a <a href="http://cqrsjourney-conference.cloudapp.net">Registrant</a> or as a <a href="http://cqrsjourney-conference.cloudapp.net:8080">Business Customer</a>:</p>
<p><a href="http://cqrsjourney-conference.cloudapp.net" alt="CQRS Journey : Conference Management System"><img src="http://cqrsjourney.github.com/images/posts/cqrsjourney-conference-v2.png" border="0"/></a> &nbsp; <a href="http://cqrsjourney-conference.cloudapp.net:8080" alt="CQRS Journey : Conference Management System - Admin Portal"><img src="http://cqrsjourney.github.com/images/posts/cqrsjourney-confmgmt-v2.png" border="0"/></a></p>
<p>We are now starting work on V3 and you can track our progress against the <a href="https://github.com/mspnp/cqrs-journey-code/issues?milestone=6">V3 milestone</a>.</p>
<p>You can read about the V2 release in more detail <a href="https://github.com/mspnp/cqrs-journey-doc/blob/master/Journey_06_V2Release.markdown">here</a> and about the V1 release <a href="http://cqrsjourney.github.com/blog/2012/05/08/Announcing-V1-Pseudo-Production-Release/">here</a>.</p>
</content>
</entry>
<entry>
<title>Plans for V2</title>
<link href="http://cqrsjourney.github.com/blog/2012/05/15/Plan-for-V2/"/>
<updated>2012-05-15T06:23:00-07:00</updated>
<id>http://cqrsjourney.github.com/blog/2012/05/15/Plan-for-V2</id>
<content type="html"><blockquote><p>Variety is the very spice of life<br/>
<em>- William Cowper, Olney Hymns (1779)</em></p></blockquote>
<p>Following on from our <a href="http://bit.ly/cqrs-v1">V1</a> release of the Contoso Conference Management System we are already well on the way toward our second pseudo-production release. This will be our first experience of handling data-versioning and software updates in an application that implements the CQRS pattern and that uses event sourcing. We plan, if possible, to be able to perform a no-downtime migration; if this proves not to be possible, we&#8217;ll make whatever changes are necessary to make sure that we can perform the V3 migration with no-downtime.</p>
<p>We have three major user stories on our backlog for this release:</p>
<ol>
<li><p>Providing a better user experience for <strong>zero-cost orders</strong> (at present the registrant is still taken to the payments system even if there&#8217;s nothing to pay). This will involve changes to our registration workflow process, adding some new events, and removing some events that are no longer needed. The Orders and Registrations bounded context uses event sourcing, so the system will need to work with both the old events (that are still in the event store) and the new events when the the new version of the workflow process is introduced.</p></li>
<li><p>Displaying the number of <strong>remaining seats of each seat type in the UI</strong>. This will require a new read-model that will need to be seeded with the correct starting values. This is because in the V1 release the Orders and Registrations bounded context was not receiving and storing the information it needs to calculate these values.</p></li>
<li><p>Adding support for <strong>discounts</strong> for seat prices through the use of promotional codes that the registrant can add during the ordering process. This introduces a brand-new bounded context implemented by a different team (<a href="http://dymitruk.com/">Adam Dymitruk</a>, one of our advisors), that needs to be integrated with the existing bounded contexts. This will also result in further changes to the registration workflow process.</p></li>
</ol>
<p>There are also several changes that will take place behind the scenes, some of which are related to the user stories described above:</p>
<ul>
<li>Modifying the application to accommodate changes to the set of events used in different versions of the system.</li>
<li>Improving the robustness of the system by ensuring that commands are always idempotent.</li>
<li>Improving the robustness of the system by ensuring that, where required, messages are always delivered in order.</li>
<li>Reevaluating our strategy for persisting integration events.</li>
<li>Evaluating some options for optimizing the command handling within the system.</li>
</ul>
<p>We plan to have V2 ready shortly to give us time to complete V3 before the end of the project.</p>
<p>You can track our progress against the <a href="https://github.com/mspnp/cqrs-journey-code/issues?milestone=5">V2 milestone</a>.</p>
<p>Feel free to provide feedback on code/guidance and <a href="http://cqrsjourney.github.com/contributors/">contribute</a>.</p>
</content>
</entry>
<entry>
<title>Specing out end-to-end scenarios</title>
<link href="http://cqrsjourney.github.com/blog/2012/05/14/Specing-Out-End-To-End-Scenarios/"/>
<updated>2012-05-14T11:18:00-07:00</updated>
<id>http://cqrsjourney.github.com/blog/2012/05/14/Specing-Out-End-To-End-Scenarios</id>
<content type="html"><h2>From mockups to features</h2>
<p>To spec out the scenarios for our <a href="http://cqrsjourney.github.com/blog/2012/03/30/Sample-Application-Overview">conference management system</a>, we’ve started with conversations with the domain experts. We’ve envisioned the user interactions with the system and captured them in mockups, like the one below:</p>
<p><img src="http://cqrsjourney.github.com/images/posts/Mockup-conf-mgmt.png" alt="Conference management mockup" border="0" /></p>
<p>Mockups helped us in many ways:</p>
<ol>
<li>Explaining our ideas in terms of UI interactions to the graphic designers.</li>
<li>Having discussions with the developers in terms of desired functionality.</li>
<li>Establishing, discussing and refining terms from our <a href="https://github.com/mspnp/cqrs-journey-wiki/wiki/Ubiquitous-language">ubiquitous language</a>.</li>
<li>Evolving our understanding of stories via “what if” scenarios rooted in the mockups.</li>
<li>Becoming a foundation for the future formulation of the acceptance tests.</li>
</ol>
<p>Based on these we’ve proceeded to develop acceptance tests using <a href="http://www.specflow.org/">SpecFlow</a>. SpecFlow provides an integrated experience for writing and executing tests in the BDD (<a href="http://en.wikipedia.org/wiki/Behavior_Driven_Development">Behavior-Driven Development</a>) style within Visual Studio. The resulting tests helped us capture, distill and refine the requirements in an unambiguous way. Here’s an example of a SpecFlow acceptance test (Feature):</p>
<p><img src="http://cqrsjourney.github.com/images/posts/Feature-conf-mgmt.png" alt="Conference management Feature sample in SpecFlow" border="0" /></p>
<p>The initial step was to write the project specifications as Feature files using the <a href="ttp://en.wikipedia.org/wiki/Behavior_Driven_Development#Application_examples_in_the_Gherkin_language">Gherkin</a> language syntax. They served well for the purpose of evolving and discussing the stories among developers and domain experts. However in that form, they could not be executed. So, from the testing perspective they would need to be executed manually if we wanted to verify whether the implemented functionality has, in fact, met our expectations.</p>
<h2>From features to executable specs</h2>
<p>Later on, we added the underlying plumbing to make sure that those features/acceptance tests can actually execute against our system-under-test.</p>
<p><img src="http://cqrsjourney.github.com/images/posts/Executable-specs-test-run.jpg" alt="Executable spec test run" border="0" /></p>
<p>We used two different approaches, both of which are valuable.</p>
<p>Because our application is a web application, for testing directly via the UI, we used <a href="http://watin.sourceforge.net">WatiN</a>, an open source library for automating Web browser testing. These tests help us gain confidence that the key end-to-end happy paths through the system work. They are fragile, however and require substantial maintenance effort.</p>
<p>Another approach for sub-scenarios is to use subcutaneous testing (or testing just beneath the UI) by directly calling the controllers (i.e. <em>Features\Registration\All Features end to end\SelfRegistrationEndToEndWithInfrastructure.feature</em>). This way we avoid coupling with the UI but
it may appear to be more complex since it requires some internal knowledge of how the system is implemented. With time, however, it became much easier to use this approach and we were able to reuse a lot of infrastructure as well as internal reuse of the parts of the test actions (these are actually called Step Definitions in SpecFlow).</p>
<h2>From executable specs to exploratory testing</h2>
<p>Of course, having the executable specs in place by no means preclude other types of testing. We recognize that good end-to-end acceptance testing requires breadth, depth, variability of actions and data, and rich scenarios, both plausible and implausible. While we value test automation for some of the scenarios, we also have professional testers on our team who are performing exploratory testing, performance testing, content testing etc. They too use the executable specs in their arsenal of tools and artefacts. The executable specs inform them of the goals of the system and some concrete scenarios.</p>
<h2>Finding your way around</h2>
<p>The SpecFlow Feature files with the business specifications were structured in the following way. All the end-to-end scenarios were grouped in a subfolder similar to <em>&#8220;Features\Registration\All Features end to end”</em> so that we could provide a quick overview of the epic (Registration in this case) and two basic reconnaissance paths through the system: one happy path and one sad (failure) path.</p>
<p>Then, in separate folders we grouped the variations of each scenario within the same epic – for example <em>“Features\Registration\Individual Reservation”</em> exercises logic for scenarios specifically for individual reservations with various seat type selections. This way we can easily separate the full end-to-end acceptance tests from more fine-grained integration tests with various permutations for each underlying scenario.</p>
<p>Regarding the implementation details, there are some general support classes that provide many shared infrastructure functions used in most of the preconditions and assertions throughout the <a href="https://github.com/techtalk/SpecFlow/wiki/Step-Definitions">Step Definitions</a>.</p>
<p>As a test runner we used <a href="http://xunit.codeplex.com">xUnit.net</a> underneath, which is supported by SpecFlow and integrates nicely with some well-known external tools like ReSharper, CodeRush, and TestDriven.NET.</p>
<h2>Getting involved</h2>
<p>One of the ways that you can get involved with us is to review and refine the existing acceptance tests or contribute new tests for existing scenarios or even planned (and not yet implemented) scenarios.</p>
<h2>Final note</h2>
<p>SpecFlow is just one tool in our testing armory. It is particularly useful as a way to help capture requirements from our Domain Experts in addition to verifying the behavior of the system.</p>
</content>
</entry>
<entry>
<title>Announcing V1 Pseudo-Production Release</title>
<link href="http://cqrsjourney.github.com/blog/2012/05/08/Announcing-V1-Pseudo-Production-Release/"/>
<updated>2012-05-08T11:45:00-07:00</updated>
<id>http://cqrsjourney.github.com/blog/2012/05/08/Announcing-V1-Pseudo-Production-Release</id>
<content type="html"><p>As part of our CQRS Journey we plan to have <a href="http://cqrsjourney.github.com/blog/2012/04/12/Road-to-V1/">several pseudo-production releases</a> of the Contoso Conference Management System so that we can explore the real-world issues of data-versioning and software updates in an application that implements the CQRS pattern in several bounded contexts. Over the next few weeks we plan more pseudo-production releases and as we go through them we will be describing our experiences in the guidance documentation.</p>
<p>Today we are releasing the first of these pseudo-production releases: Contoso Conference Management System (V1).</p>
<p><img class="left" src="http://cqrsjourney.github.com/images/posts/cqrsjourney-conference-v1.png"></p>
<p>The current release consists of three bounded contexts:</p>
<ul>
<li><em>Conference Management</em> (implemented using a traditional CRUD-style architecture).</li>
<li><em>Orders and Registrations</em> (implementing the CQRS pattern and using event sourcing).</li>
<li><em>Payments</em> (implementing the CQRS pattern and using a SQL-based storage).</li>
</ul>
<p>Keep in mind, while based on the real-world requirements, it is still a <u>sample</u> application. It doesn’t include the following:</p>
<ul>
<li>Authorization (on the backlog for V2).</li>
<li>Styling for the conference management web site (on the backlog for V2).</li>
<li>Integration with a real third-party payment processor (out of scope for the guidance project; we&#8217;ll keep the simulated one).</li>
<li>Conference details (description, speakers, tracks, sessions, etc.) - you will see static data in the registration hub for now.</li>
<li>Perf testing (on the backlog for V3).</li>
</ul>
<p>If you would like to explore the code in the V1 release, you can <strong>download it from GitHub <a href="https://github.com/mspnp/cqrs-journey-code/tree/V1-pseudo-prod">here</a></strong>.
To help you get started with building/deploying/running the V1 release code see the release notes <a href="https://github.com/mspnp/cqrs-journey-doc/blob/master/Appendix1_Running.markdown">here</a>.</p>
<p>The current release uses the Windows Azure Service Bus to provide its messaging infrastructure and can be deployed to Windows Azure. You can access a deployed version of the application as a <a href="http://cqrsjourney-conference.cloudapp.net">Registrant</a> and as a <a href="http://cqrsjourney-conference.cloudapp.net:8080">Business Customer</a>. Please feel free to use the application and to generate some sample data for us so that we can migrate it for our V2 release.</p>
<p>Note: You can also run a copy of the application locally without using Windows Azure or Windows Azure Service Bus as described in the <a href="https://github.com/mspnp/cqrs-journey-doc/blob/master/Appendix1_Running.markdown">release notes</a>.</p>
<p>We would appreciate your feedback on both the code and the written guidance. You can submit your reviews either via GitHub (comments, pull requests, issues) or via our <a href="http://pundit.cloudapp.net">lightweight review system</a>.</p>
<p>If you&#8217;d like to participate in this sample system evolution and work on any improvements of the existing bounded contexts or new ones, check out <a href="https://github.com/mspnp/cqrs-journey-code/issues">our backlog</a>. We&#8217;ll be happy to see your pull requests!</p>
</content>
</entry>
<entry>
<title>Open Call for Enhancements to Event Store Implementation</title>
<link href="http://cqrsjourney.github.com/blog/2012/05/01/Open-Call-For-Enhancements-To-Event-Store/"/>
<updated>2012-05-01T10:36:00-07:00</updated>
<id>http://cqrsjourney.github.com/blog/2012/05/01/Open-Call-For-Enhancements-To-Event-Store</id>
<content type="html"><p>In the process of our conversion of the Registration process BC to use event sourcing, we have realized we needed some robust event sourcing infrastructure (both for storing the events, and publishing them). We wanted this implementation to be Windows Azure-friendly, as this is where we’ll bedeploying our system to.</p>
<p>We have now built our initial implementation of the Azure table-based event store and it’s ready for a broad community review and for enhancements. It seems to be self-contained enough and will benefit from crowd-sourcing. Get it from here:</p>
<ul>
<li>Repo: <a href="https://github.com/mspnp/cqrs-journey-code">https://github.com/mspnp/cqrs-journey-code</a></li>
<li>Infrastructure solution: <a href="https://github.com/mspnp/cqrs-journey-code/blob/dev/source/Infrastructure.sln">https://github.com/mspnp/cqrs-journey-code/blob/dev/source/Infrastructure.sln</a></li>
</ul>
<p>We really look forward to your participation in getting this event store production ready!</p>
<p><em>Notes:</em></p>
<ol>
<li><p>This is currently not intended to be a general-purpose, pluggable component. We’ve designed and developed it to fit with our sample application.</p></li>
<li><p>There’s another implementation based on SQL server. It is meant for running the sample app locally and it’s not ready for production. Nor is it in our scope to make it production-ready. So, when prioritizing where to direct your effort, please choose the Azure table-based implementation.</p></li>
</ol>
</content>
</entry>
<entry>
<title>The Road to V1</title>
<link href="http://cqrsjourney.github.com/blog/2012/04/12/Road-to-V1/"/>
<updated>2012-04-12T15:40:00-07:00</updated>
<id>http://cqrsjourney.github.com/blog/2012/04/12/Road-to-V1</id>
<content type="html"><h2>Handling Complexity and Change</h2>
<blockquote><p>DDD and ES reduce complexity and cost of change. They would look like useless magic in stable and predictable projects.<br/>
<em>- Rinat Abdullin, CQRS Advisors Mail List</em></p></blockquote>
<h2>Introduction</h2>
<p>One of the topics discussed on the CQRS Advisors Mail List was how to make the CQRS Journey Project more realistic. In the real world, projects face uncertainty, risk, and volatility in requirements. One of the benefits of applying ideas from DDD and using event sourcing is to make that uncertainty, risk, and volatility more manageable.</p>
<p>As part of our CQRS Journey, we are planning a pseudo-production release of V1 of the Contoso Conference Management System that includes the core conference management functionality. We will then explore, and document our experiences of enhancing and maintaining the V1 release as we continue to work on the Conference Management System.</p>
<h2>Contents of the V1 Release</h2>
<p>The following sections outline our planned functionality for the V1 release.</p>
<h3>Conference Management</h3>
<p>This will be a simple CRUD style bounded context that enables a <a href="https://github.com/mspnp/cqrs-journey-wiki/wiki/Ubiquitous-language">Business Customer</a> to create and manage conferences. A Business Customer will be able to:</p>
<ul>
<li>Create and update the conference data such as name, description, and dates.</li>
<li>Publish and un-publish a conference.</li>
<li>Manage the <a href="https://github.com/mspnp/cqrs-journey-wiki/wiki/Ubiquitous-language">Seat Types</a> (e.g. full-conference, workshop, cocktail party) available at a conference.</li>
<li>View a list of <a href="https://github.com/mspnp/cqrs-journey-wiki/wiki/Ubiquitous-language">Attendees</a>.</li>
</ul>
<h3>Registrations</h3>
<p>This bounded context will implement the CQRS pattern and use event sourcing. The functionality in this bounded context includes:</p>
<ul>
<li>Enabling a <a href="https://github.com/mspnp/cqrs-journey-wiki/wiki/Ubiquitous-language">Registrant</a> to create an <a href="https://github.com/mspnp/cqrs-journey-wiki/wiki/Ubiquitous-language">Order</a> for seats at a conference.</li>
<li>Handling partial fulfillment of Orders.</li>
<li>Enabling a Registrant to locate a previously created order using an <a href="https://github.com/mspnp/cqrs-journey-wiki/wiki/Ubiquitous-language">Access Code</a>.</li>
<li>Enabling a Registrant to assign Attendees to Seats.</li>
<li>A task-based UI.</li>
</ul>
<h3>Integration</h3>
<p>The Conference Management and Registrations bounded contexts will be integrated so that any changes made by the Business Customer to the quota of Seats at a Conference are detected by the Registrations bounded context. Information about the Attendees is also shared between the two bounded contexts.</p>
<h3>Payments</h3>
<p>Part of the Registration Process includes the Registrant making a payment for the Order. The system will include a fake payment service that simulates handling payments by credit card and by invoice.</p>
<h3>Infrastructure</h3>
<p>The Contoso Conference Management System will be deployed to Windows Azure and use the Windows Azure Service Bus to provide its messaging infrastructure for Commands and Events. It will also be possible to run the application locally without requiring a Windows Azure subscription.</p>
<h2>More Information</h2>
<p>You can follow our work in these two GitHub repositories:</p>
<ul>
<li><a href="https://github.com/mspnp/cqrs-journey-doc">cqrs-journey-doc repository</a></li>
<li><a href="https://github.com/mspnp/cqrs-journey-code">cqrs-journey-code repository</a></li>
</ul>
<p>You can track our progress against the V1 release milestone:</p>
<ul>
<li><a href="https://github.com/mspnp/cqrs-journey-code/issues?milestone=4">V1 Release Milestone</a></li>
</ul>
</content>
</entry>
<entry>
<title>Sample Application Overview</title>
<link href="http://cqrsjourney.github.com/blog/2012/03/30/Sample-Application-Overview/"/>
<updated>2012-03-30T10:15:00-07:00</updated>
<id>http://cqrsjourney.github.com/blog/2012/03/30/Sample-Application-Overview</id>
<content type="html"><h2>Contoso Conference Management System</h2>
<p>This post summarizes the key features and functionality of the proposed Contoso Conference Management System that we are builing in our CQRS Journey projects.
You can read our motivation for choosing this domain <a href="http://blogs.msdn.com/b/agile/archive/2012/01/24/picking-a-domain-for-cqrs-journey-ri.aspx">here</a> and <a href="https://github.com/mspnp/cqrs-journey-doc/blob/master/Journey_00_Preface.markdown">here</a>.</p>
<h2>Introduction</h2>
<p>Contoso plans to build an online conference management system that will enable Contoso&#8217;s customers to plan and manage conferences that may be held at a physical location. The system will enable Contoso&#8217;s customers to:</p>
<ul>
<li>Plan the tracks, sessions, and speakers that make up a conference.</li>
<li>Manage the calls for speakers and paper submission process.</li>
<li>Manage registration (the sale of seats) for the conference.</li>
<li>Manage the conference on site, including badge printing and attendee lists.</li>
</ul>
<p>The following sections describe these functions in more detail.</p>
<h2>Overview</h2>
<p>The Conference Management System will be a multi-tennant, cloud-hosted application. Business customers will need to register with the system before they can create and manage their conferences.</p>
<h2>Conference Planning</h2>
<p>When a business customer creates a new conference, he must first define some characteristics of the conference such as:</p>
<ul>
<li>Will the paper submission process require reviewers.</li>
<li>What will be the fee structure for paying Contoso.</li>
<li>Assigning key personnel such as the Program Chair and the Event Planner.</li>
</ul>
<h2>Building a Program</h2>
<p>The business customer must define the conference program. For a simple conference this may be defined directly. For a more complex conference this may involve several steps:</p>
<ul>
<li>Identifying Tracks and Track Chairs.</li>
<li>Identifying Reviewers.</li>
<li>Making calls for submissions.</li>
<li>Reviewing the papers and assigning speakers to sessions.</li>
<li>Finalizing Track programs.</li>
</ul>
<h2>Selling Seats</h2>
<p>The business customer will define how many seats are available for the conference and also for any events that are part of the conference that only limited numbers may attend.</p>
<p>The system must manage the sale of seats to ensure that the conference and sub-events are not over subscribed. This part of the system will also operate wait-lists so that if cancellations are made, then the seats can be re-allocated.</p>
<p>The system will require that the names of the attendees are associated with the purchased seats so that badges can be printed.</p>
<h2>On-site Management</h2>
<p>When attendees arrive at the conference they should be registered against an attendee list, given badges, and given the opportunity to purchase additional seats for any extra events they would like to attend. The system that runs on-site at the conference should not assume that it is permanently connected to the main conference management system.</p>
<h2>Additional Features</h2>
<p>Contoso plans to roll out additional features as and when resources are available. These include:</p>
<ul>
<li>Support for Event Planners to manage equipment, signage, etc.</li>
<li>Tracking attendees at sessions via a barcode on the badge.</li>
<li>Score submissions for session feedback.</li>
<li>Live feed of session scores to track the best sessions.</li>
<li>Reporting feeback to speakers.</li>
<li>Archiving conference materials.</li>
<li>Publishing proceedings.</li>
</ul>
<h2>Ubiquitous language</h2>
<p><a href="https://github.com/mspnp/cqrs-journey-wiki/wiki/Ubiquitous-language">Here</a> are the working definitions for the terms in our ubiquitous language for the Conference Managament System sample we are building. We will be adding to and modifying this list as the project proceeds&#8230;</p>
<h2>More info</h2>
<p>Follow our progress in these 2 repos (you can set the watchers):</p>
<ul>
<li><a href="https://github.com/mspnp/cqrs-journey-doc">https://github.com/mspnp/cqrs-journey-doc</a></li>
<li><a href="https://github.com/mspnp/cqrs-journey-code">https://github.com/mspnp/cqrs-journey-code</a></li>
</ul>
</content>
</entry>
<entry>
<title>Taking Community Contributions</title>
<link href="http://cqrsjourney.github.com/blog/2012/02/25/Taking-Community-Contibutions/"/>
<updated>2012-02-25T06:45:00-08:00</updated>
<id>http://cqrsjourney.github.com/blog/2012/02/25/Taking-Community-Contibutions</id>
<content type="html"><p>We have positioned the CQRS guidance project as a learning journey. We’ve formed a stellar <a href="http://cqrsjourney.github.com/advisors/members/">advisory board</a> and performed some <a href="http://www.surveymonkey.com/s/cqrsguide">public consultation</a> that helped us scope the project initially. While this is good news, we recognize that for this project to be successful, we need to be not only open and transparent, but we also need to collaborate with the community (in its way a global village) more closely. That’s why we are extremely happy and proud to announce that for the first time in the history of the <a href="http://msdn.com/practices">Microsoft patterns &amp; practices</a> team, the following: <strong>In the true spirit of open source, we will be taking community contributions on the CQRS Journey project</strong>. This means:</p>
<ul>
<li>The written guidance and the sample code will be developed in the open and with community involvement.</li>
<li>We, Microsoft patterns &amp; practices team, will review and accept contributions that meet our guidelines.</li>
<li>The final deliverable will have an open source license (<a href="http://opensource.org/licenses/Apache-2.0">Apache 2.0</a>).</li>
</ul>
<p>The project will be hosted on GitHub. Our repositories are:</p>
<ul>
<li><strong>Main code repo</strong> - <a href="https://github.com/mspnp/cqrs-journey-code">https://github.com/mspnp/cqrs-journey-code</a>. Also, includes our prioritized backlog of work items (published under <a href="https://github.com/mspnp/cqrs-journey-code/issues">Issues</a>) and includes stories, dev and test tasks, and bugs.</li>
<li><strong>Guidance repo</strong> - <a href="https://github.com/mspnp/cqrs-journey-doc">https://github.com/mspnp/cqrs-journey-doc</a>. Also, includes the backlog of doc stories, tasks, and content bugs.</li>
<li><strong>Project wiki</strong> - <a href="https://github.com/mspnp/cqrs-journey-wiki">https://github.com/mspnp/cqrs-journey-wiki</a>, where we will try to reconcile various key CQRS and ES related terms and also maintain the ubiquitous language for the domain of the sample application we are building.</li>
</ul>
<p>You can find the contributions guidelines under Contribute section.</p>
<p>Also, check out our company-wide <a href="http://www.microsoft.com/en-us/openness/default.aspx#home/videos/Commitment-to-Openness">openness initiative</a> and brace yourself for a ride! We look forward to working with you! Please keep sending us your feedback.</p>
</content>
</entry>
</feed>