|
Yes, find the entities/resources in the domain, model them, model their state and what makes them change state. Give names to those states and what makes them change. Applied this to a public transport ticketing system, it has entities like "Patrons", "Tokens", "Trips", "Fares", "Passes", "Stations" etc. Patrons can be registered or de-registered. Tokens can be Assigned, Unassigned, Blocked. Trips can be Entered, Exited, Completed. Tokens are used by Passengers (which are different to Patrons, think Parent buys a Token for Child that is travelling). Model each of those Nouns and define the verbs that change them (eg Register Patron leads to a Patron Registered event). DDD Smells: Words like "create", "delete", "modify". Betterer names are things like "register", "suspend", "assign", etc. Focus on the Nouns and then the Verbs will follow. A lot of design seems to be on workflows and treat the Nouns as passive things that get changed. I think of how it would work if people were doing it, not computers. I want to open an account at a bank. So there are two actors so far, me, and the bank. There's a Noun, an "account". What can an account do? Well, from that sentence, it can be opened. Who can open one? What is a name for me? Customer? AccountHolder? Client? etc. What are the details about the "bank", it has Branches and Ledgers and etc. Note that absolutely none of what I've described above is about implementation. Some of the gotchas are thinking that, for example, de-registering a patron is the same as deleting them. Developers love to model everything as CRUD, whereas CRUD are data operations, not a domain activity. Its very rare that you want to actually delete an entity. Accounts get Closed, but they don't get deleted. They get Archived. |
Back in my student days we were taught about a role called "system analyst" I think it was part of COBOL. They have deep domain expertise and work with programmers to automate business workflows. Their job is to identify the entities you pointed out (patrons, trips etc.,) and clearly document all the interactions and workflows. They then figure out what kind of workflows need to be automated, to what extent and so on. They also are supposed to ensure that disruptions to existing systems/processes/people are kept at a minimum level. Note that these system analysts are not air-dropped product-managers but rather people who have been working inside the system for decades. They know all the edge cases, context, and more importantly history so they know why a certain Chesterton's fence exists.
I haven't come across such folks in my professional life. So engineers are expected to learn and automate a domain at the same time. It just doesn't work that way. No wonder many of the IT systems have been a disaster. Implementors discover, to their horror/surprise, that the real world is full of edge cases. Take Uber for example. The first launch didn't include tipping. It was a monumental effort to retrofit that into their payment processing and ride handling systems.