"You have terms from different phases of development in your terminology. That's fine. But then we want to know which phase would be the most abstract to introduce a term. For example, the event sign-up request submitted is not from the domain: in the domain we do not have the system-to-be and therefore there are no users, no accounts, no sign-up, etc. So, what's the phase or stage or abstraction level that's the most abstract and which makes this term necessary?
Also, an action like "create resume" in the way you describe it, is an action that a user carries out on the system-to-be. But there's also an action at the level of the domain, the action that is concerned only with how the concepts relate to one another. It would look very similar, but with a different focus.
"Browse resumes": if the user browses through resumes stored in their account with this function, then the function needs access to the resumes. Where does that access come from? As you formulated it, the function does not have access neither to the user's account nor to the resumes stored in the account, it only has access to a list of browse criteria, but from those alone, how should it get the resumes?
Would "compile experience" create a resume? Or is the compiling a step before the actual creation of the resume? And the creation of the resume is then a next step that draws on the information previously compiled? You use CompiledResume as the resulting type/sort of the operation, but that's not a concept that you have defined anywhere.
You need to walk through scenarios with your concepts to see whether they fit what you need. Try telling a story about how a scenario could play out using only the terms you have defined and only in the strictest sense in which you have defined them. This way you can spot for example that you have a operation that generates a CompiledResume, but you have no other operation that can work with a value of that type.
Similarly, if you consider how "create resume" and "edit resume" work together, you see that create resume must result in a resume, so we check what your definition of resume is and we see "A document that consists of an account of a person’s personal information, professional experiences, education, skills, and certifications tailored for job applications." We see that it's a document. But in the "edit resume" description the resume gets edited and the template is not mentioned again. Which is okay, if we assume that the template can be obtained from the resume. But then the resume is not purely a document, it then is a description of how the recreate the document. But if we go this far then why not also have links from the resume to the PersonalInformation, Contact, etc. and updating the information used on the resume would then just mean updating the link to the respective component. I'm not saying that you must do it in the way I explore here, but what you must do is to explore how you can make the parts fit together better.
Events are instantaneous! Events do not take anyone/anything to "do" them! So, "Template selection interface is displayed to the user." (even though passive voice) is not an event if we read it as "the system will display the template selection to the user". Admittedly, this could be read as an event, if one would read "the display of the template selection has just become ready (i.e. generating the display has just ended)". But there are also other claimed events where such a reading as an event it no longer possible for example "User engages in self-reflection activities." Here the user needs to do something and so we have an actor and we have duration because the self-reflection is not instantaneous."
Keiven-Soto
commented
5 months ago
"You have terms from different phases of development in your terminology. That's fine. But then we want to know which phase would be the most abstract to introduce a term. For example, the event sign-up request submitted is not from the domain: in the domain we do not have the system-to-be and therefore there are no users, no accounts, no sign-up, etc. So, what's the phase or stage or abstraction level that's the most abstract and which makes this term necessary?
Also, an action like "create resume" in the way you describe it, is an action that a user carries out on the system-to-be. But there's also an action at the level of the domain, the action that is concerned only with how the concepts relate to one another. It would look very similar, but with a different focus.
"Browse resumes": if the user browses through resumes stored in their account with this function, then the function needs access to the resumes. Where does that access come from? As you formulated it, the function does not have access neither to the user's account nor to the resumes stored in the account, it only has access to a list of browse criteria, but from those alone, how should it get the resumes?
Would "compile experience" create a resume? Or is the compiling a step before the actual creation of the resume? And the creation of the resume is then a next step that draws on the information previously compiled? You use CompiledResume as the resulting type/sort of the operation, but that's not a concept that you have defined anywhere.
You need to walk through scenarios with your concepts to see whether they fit what you need. Try telling a story about how a scenario could play out using only the terms you have defined and only in the strictest sense in which you have defined them. This way you can spot for example that you have a operation that generates a CompiledResume, but you have no other operation that can work with a value of that type.
Similarly, if you consider how "create resume" and "edit resume" work together, you see that create resume must result in a resume, so we check what your definition of resume is and we see "A document that consists of an account of a person’s personal information, professional experiences, education, skills, and certifications tailored for job applications." We see that it's a document. But in the "edit resume" description the resume gets edited and the template is not mentioned again. Which is okay, if we assume that the template can be obtained from the resume. But then the resume is not purely a document, it then is a description of how the recreate the document. But if we go this far then why not also have links from the resume to the PersonalInformation, Contact, etc. and updating the information used on the resume would then just mean updating the link to the respective component. I'm not saying that you must do it in the way I explore here, but what you must do is to explore how you can make the parts fit together better.
Events are instantaneous! Events do not take anyone/anything to "do" them! So, "Template selection interface is displayed to the user." (even though passive voice) is not an event if we read it as "the system will display the template selection to the user". Admittedly, this could be read as an event, if one would read "the display of the template selection has just become ready (i.e. generating the display has just ended)". But there are also other claimed events where such a reading as an event it no longer possible for example "User engages in self-reflection activities." Here the user needs to do something and so we have an actor and we have duration because the self-reflection is not instantaneous."