Alternatives to DDD - Complicated and cumbersome business logic/process

Question

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.

Answer 1

There is no architecture, design pattern or development philosophy that fixes this. Domain-driven development was conceived precisely for complex applications. Eric Evan's book "Domain-Driven Design: Tackling Complexity in the Heart of Software" mentions the word "complexity" in the title for a very good reason. Managing complexity is at the core of domain-driven design.

As I see it, you have two main challenges here (in this order):

1. Understanding their business logic.
2. Applying a different set of business rules when the "jar fills up".

You will need the help of a large number of domain experts to understand the process. Start with a "big picture" view of the rules — think "executive summary" — and then break things down into smaller and smaller requirements. After that, understand any external dependencies and why they are necessary. For instance, if aggregating data from outside resources, understand why this is happening. You might need to model these phase transitions. Each entity needs flexibility, but at some point a new business process takes over with more stringent rules. This collaboration is what needs to be modeled.

Deciding which development philosophy to use is very subjective. It requires deep knowledge of the domain being modeled. For extremely complex domains, DDD is a good fit. Don't abandon this simply because you cannot see a good place to start. Instead, start with gaining a very deep and complete understanding of the business rules. Organize and record them however your team works best. Only after you have gained this insight can you begin discussing architecture, design patterns and development philosophies.