We have inherited a legacy MS CRM 4.0 application and the business wants it re-written to an as vanilla as possible .NET web application. The business wants to go down this route vs another off-the-shelf CRM solution because their business logic is very bespoke and off-the-shelf solutions offer very little out of the box that it actually uses. They got stung with this before developing the CRM 4.0 system which had to be heavily butchered to implement their business logic.
So background on the app itself, CRM 4.0 has a concept of 'entities' that are basically mapped 1:1 to the DB, if you create a 'Person' or a 'Car' entity then it will create a 'Person' or a 'Car' table in the DB and every attribute or relationship (1:1, 1:N etc) it will generate and manage, including all the FK relationships. It then offers forms that you can customise that offer bog standard CRUD operations against those tables.
To implement any sort of business logic you need to write plugins that get registered into the entity CRUD pipeline (pre or post), so if you need some logic to execute before you save a Car entity you write a CarPlugin that you register against the 'Pre' action on the save event, that plugin will then get fired before you save that record to the DB. Plugins can be fired Pre or Post action and can be ordered if you have multiple plugins registered to the same Pre or Post condition.
So obviously our (small dev team) first thoughts on this re-write leans towards DDD, Clean, CQRS etc but we're really struggling with trying to model the business logic into domain entities, aggregate roots etc. The issue we're running into is the business logic and processes just don't seem to lend itself well to DDD, this is both a domain issue (i.e. the domain is just very complicated and messy), legacy processes that just aren't going to or can't change and probably a lack of experience on our part.
The problem is the field we are working in is very bureaucratic and requires the collection of a LOT of data, data that can come in dribs and drabs and different orders over various time periods. That data is collected, entered into the system then there's a point at which when we have all the required data (spread over about 10 entities) the main entity becomes 'active' which requires validating all the other entities and required data. The way it was described to me was you have a jar of data, and you have to fill that jar up with the required data and once the jar is full you can then move on to the next stage.
The main entity itself has about 50+ fields, then you have all the associated entities, it's a lot of data. Currently users are presented with one big form for that entity, with about 5 or 6 tabs, they can edit and add data over time then comes a point where they click 'set active', the system checks all the data and either throws validation errors or succeeds and the record becomes active.
Because of how the business operates, there is no real scope to reimagine or redesign their processes, the UI will have stay pretty much as it is (or as close as), the way we receive data isn't going change (out of our control).
So tl;dr: We have a large spaghetti junction CRUD system with all the business logic baked into plugins and we need to translate it to a halfway sensible .NET application that is maintainable.
Every example I see of a DDD example application it's dealing with Shopping Carts and stuff like that, I WISH our system was that simple. So any thoughts on the direction we should take this in would be greatly appreciated.