Traditional way of building CRM solutions that you may find on internet forums and youtube consists of separate Plugins.dll and Workflow.dll and business logic is written directly into these dlls. This works fine for small demo projects but poses a challenge when solution grows.

  • Entity specific logic exists in 2 places, makes hard to see the whole picture or refactoring just by looking at entity class
  • Difficult to unittest if entity class is coupled with CRM wiring and plugin registration code

I suggest to structure a code using Domain Driven Design model where your entity classes become infrastructure independent and reside in one place. Then Plugins.dll and Workflows.dll would contain only registration plumbing code and actual logic will be done by Domain entity. This helps containing logic in one place and you can easily unittest “clean” Domain entities. Here is diagram:

Since IL Merge is not officially supported, developers can use “Linked File” in Visual Studio instead when adding Domain files to Plugin/Workflow solutions.

Additional advice would be to keep as much business logic as possible inside C# code which is source controllable, refactor-able and testable rather then spreading entity logic in multiple places like JavaScript forms, Workflows, Plugins and Rules.

Leave a Reply

Your email address will not be published. Required fields are marked *