Create documentation

[dvdstelt]

PoA

• [ ] NServiceBus

  • [ ] Routing configuration
    • [ ] Add snippets from the solution to illustrate how it's configured
  • [ ] Describe

• [ ] Transport

  • [ ] RabbitMQ

• [ ] Persister

  • [ ] Cover in memory persistence that we're currently using
  • [ ] Cover SQL Persistence when it's added
    • [ ] Explain how to configure/create dbs in Docker
    • [x] Explain that scripts are auto-executed, but can (should?) be disabled in production

• [ ] SI

  • [ ] Explain how to set it up
  • [ ] Add screenshot with visualization

• [ ] SP

  • [ ] Explain how to set it up
  • [ ] Add screenshot with visualization

• [ ] Serialization

  • [ ] Explain behavior to fallback on type of message, because contracts aren't shared.
  • [ ] Explain this is a deployment issue and doesn't have to be 'decoupled' in VIsual Studio.

• [ ] Outbox

  • [ ] Catalog Service
    • [ ] Removed EventLog and enabled NServiceBus Outbox Especially check OrderStatusChangedToAwaitingValidationIntegrationEventHandler as it's extremely easier than before.
    • [ ] IntegrationEventMigrations removed.
  • [ ] Ordering Service
    • [ ] IntegrationEventMigrations removed.

[dvdstelt]

@Particular/tf-eshop I started writing stuff down here that needs explanation in documentation on our own repo.

[weralabaj]

@dvdstelt I started working on a draft here https://docs.google.com/a/nservicebus.com/document/d/1iPVxUHMBAIwuYph65u1wn56gzWSoxoC_mrCl_VfABRA/edit?usp=sharing

SQL Persistence using JSON

That could be skipped until we implement a saga, correct? I don't think it's important for now to explain JSON part, as this is used for sagas only.

Scripts are auto-executed, but can (should?) be disabled in production

I think 1 sentence is enough and just link to doco about installer workflow and ms sql server scripts

Explain behavior to fallback on type of message, because contracts aren't shared. Explain this is a deployment issue and doesn't have to be 'decoupled' in VIsual Studio.

Not sure what you had in mind here, do we need more than what's said re: message contracts and routing?

Outbox, transactions, etc.

Still trying to figure out what exactly they do, how, why and what they said in the ebook about it. So treat it as a very rough draft :P

[weralabaj]

@dvdstelt I updated the description to cover things I know we discussed but haven't done yet, though starting with Serialization to the end I'm not sure what is the plan and what you had in mind, can you clarify?

[dvdstelt]

@weralabaj It should explain ducktyping and the fact that shared assemblies isn't a bad practice. Just like the original eShopOnContainer solution, it was 100% the same C# code, except in different projects. Why not have this 100% same code in a single, shared assembly? The result in coupling and deployment is exactly the same. If a user has issues with versioning, for example, it's even easier with our solutions. Redirect them to our doco on versioning.

Does that make sense? I can write the doco as well.