You are not logged in.
Pages: 1
As I have said before, I'm coming back with this new software proposal to develop (to model a real application as an example, through DDD and mORMot). This is the design:
Introducing the system: the initial requeriments
I want to develop a software to estimate projects, and break them into tasks. Besides, I should be able to estimate the time to complete these tasks. I should be able to impute works done on a task (and the time invested in doing it), too.
So, with this new software, I must be able to:
- Define a project and break it into tasks.
- Define works done (related to a task).
- Generate “timesheets” (estimated time, invested time...), to budget them, or to invoice them, or to check the time invested in them.
- Generate a workday “sheets” (with the invested times on), to report the workday of an employee.
[GitHub Repository: https://github.com/Atp-Rds/PWMS ]
The Model of the “Projects&Works” domain (class diagrams):
View the class diagrams:
- Class and associations: https://github.com/Atp-Rds/PWMS/blob/ma … Basic).jpg
- Aggregates, Entities, associations (constrained): https://github.com/Atp-Rds/PWMS/blob/ma … &Asso).jpg
I define this four user-level application functions (to assign to a four application layer classes):
- To define projects (to create projects, related tasks, and estimate them)
- To add works (to impute works done related to a task)
- To generate the WorkDay timesheets
- To check the related times of a given project.
And the Repositories of the aggregates: https://github.com/Atp-Rds/PWMS/blob/ma … ories).jpg
In the next steps, I will implement the (isolated) domain classes, the main structure, and the tests (with test driven design approach and mORMot).
But before that, some questions about the domain model:
- Do you think that is clearly defined? (entities, aggregates, and so on)
- Would do you change something to refine the model? (Ubiquitous language, relationships, applications…)
- Anything else to comment on?
I hope I have expressed myself...
Thanks to all!
Thanks for your time, ab!
Sure, the main problem is what you say at last sentence: The domain is not clear, and the boundary contexts are not clearly defined, because the sample is too abstract... I have tried to represent the relationship between entities from a relational storage DDD approach, instead of a “perfect” DDD approach, starting at entities instead of the domain and use-cases… I will prepare a clearer (and realistic) sample project with mORMot, try to fit it to a) approach, with a real problem to model (at least I’ll try!)
I want to design the domain model first (a basic functionality, ignoring the details), and develop the first approach with mORMot, in an iterative way, to learn more about DDD and the mORMot capabilities to “implement” it, in a “real-life” scenario. I’ll try to share the code and the process to model and develop it if it can help the community (in addition to myself), and I will ask for some help from you all, if you want, in case I’ll be lost or if I’ll be confused.
Perhaps, it could be useful for others developers…
I'll come back again soon
I'm really impressed with mORMot framework, my sincerely congratulations to Arnaud Bouchez and all the contributors, it’s amazing!
I discovered it a few years ago, and I’m incorporating it in my projects developed in Delphi. I want to incorporate DDD too, and I develop a test project to try to understand better how DDD works, with mORMot framework too. I have studied samples, presentations, mORMot documentation, and forum threads, and I have some doubts and questions related.
I have implemented this sample project: https://github.com/Atp-Rds/DDDFamily.git, it tries to simulate a "family" (simplified) with 3 members (mother, father and son), and their relationships, starting from the objects (avoid to start from DB), and store aggregate as a whole (see more details at ReadMe.md).
You can see that main architecture and structure tries to follow the DDD practical samples by ab at EKON… my main doubts/questions at the moment are:
1. From DDD point of view, and mORMot capabilities, are this structure well defined?
2. If you need to update a property, like a Mother’s name (see function "ChangeMothersName" at dom\DomFamilyServices.pas), that affects several aggregates… Is correct the approach of this function? (the complexity to update them grows up when objects become more complex)
3. You can see that Son aggregate includes all the properties of mother and father aggregates, and family aggregate includes all properties of all related aggregates (see the TSQLRecord* classes at infra\Infra*Repository.pas) … when you store these aggregates, all of these fields are stored as a whole in each table related, introducing data redundancy but isolating it from other tables (the same data are stored in the mother table, the son table and the family table, but all of them acts as isolated aggregates)…
But what happens if the objects become more complex, with a lot of properties, and they introduce properties "TObject" recursively? (imagine that TMother class have two new properties, mother and father ... in other words, TMother can be a TSon) ... these properties, should be relationships by TSQLRecord's Ids instead of store all properties on the aggregate? But in this case, the repository factory class (TInfraRepo*Factory) can’t establish relationships between TDDDObject and TSQLRecordObject…
I'm a little bit confused at this point...
Any feedback is welcome, and sorry for my (bad)English
Thank you very much to all!
Regards,
Hi warleyalex,
the link is down, can you upload it again?
Thanks a lot for sharing!
Pages: 1