Does the following image (i.e. a non-navigable composition relation) makes sense in an early-stage UML class diagram of a Domain Model?
I want to express that it will not be possible to do Company.Accounts, but that if the Company object is destroyed, all Accounts are to be destroyed too. My motivations are to avoid the Company class to become some kind of God-Object anti-pattern as discussed in this question. In DB terms: there's a foreign key from Account --> Company. In the actual app, just about everything will be owned by the Company and, for performance reason, I don't want to allow lazy/eager loading all the child collections from the Company.
I imagine the final diagram would probably have an IAccountRepository (see following image) but I find that it burdens the Class Diagram to put everything there. Imagine adding the extra infrastructure classes for each child collection. The class diagram would become unreadable!
How do you convey the idea in the Domain Model that loading is going to be "indirect"? Does it even go there?
Any references or industry standard on this?
Thanks.
You are mixing behavioral modeling with static model. The relation you set between Company and Account is OK if Company never accesses Account directly, but if you have functions in Company that access Account, then your model is wrong.
From what I know, there is no way to model that on the one side Company is composed of Accounts but that the accounts are actually stored in another place. Your second diagram is not correct, because if Company is composed of Accounts, then IAccountRepository should access them through Company and not directly.
IMHO, Account should have composition from IAccountRepository to Account, association from Company to Account, and in a sequence diagram of ICompanyRepository.deleteCompany that when a company is deleted, all of it's accounts are deleted.
Related
I am incredibly new to Domain Models and I am trying to build up my understanding. I have created this domain model around a scenario which I will provide. I feel this model is simple and as a result, feels incorrect and might be missing elements I might not have thought of although, I cannot think of what else might need to be included in a domain model given the scenario. The idea is to demonstrate the relationship between real world class entities which I feel I have managed to achieve.
Scenario: Management Application that allows you to create users, projects, companies and issue tickets. The projects are assigned to companies, the users are assigned to projects and the issue tickets are assigned to the users. Tickets have a status which can be changed.
Changes
Implementing proposed changes. I think this is a better way to represent the idea based on the feedback returned, especially in regards to the use of composition. I have also updated the multiplicities to better represent the scenario.
Further changes
The diagram should stay as simple as possible, but not more.
In this specific case:
The two specializations of User might be too complex for the need: a User stays a User, isn’t it? If you really need to take into account differences between categories of users, and especially if the category changes over time, you'd better consider (object) composition over inheritance (or better worded for UML: prefer association over inheritance).
The associations might be too simple or incomplete. For example, before an Issue ticket gets assigned to a User, isn’t it also associated to a Project or a Company? It is not clear either if User is also associated to Company (e.g. multi-tenant cloud scenario) or if there is no such association (e.g service provider scenario, where the company is in fact a customer company).
Some associations may hide association classes, e.g. do you expect to monitor how many time a user worked on a ticket?
It entirely depends on the purpose of your model.
Some models might be created to stimulate discussion and further discovery. Some might be required for the senior stakeholders to approve. Some might be for developers to work from. Others might be for marketing material.
Your model is ok for stimulating discussion and further discovery.
I am currently working on the use cases for a car sharing app.
The simple diagram for the process of registration looks like this:
At the moment I am stuck with the following scenarios.
When a new customer is registered, a process is carried out at the head office (central)in which the following points are checked
Scenario 1 - Head office side:
1. The identity of new customers is carried out externally with
the post. Two possibilities: presenting the identity card at a post office branchor carrying out by video.
2. The verification of the customer's bank details is carried out externally with the bank.
3.The system will verify that the contact details (email address) are correct
4.the consent to the GTC has been obtained
My sketch for the confirmation process looks like this:
How do I show that the system verifies that the contact details (email address) is correct ? How do I show that consent to the GTC has been given ?
Scenario 2 - Customer's side: A customer can view and edit the information of his registration.
1.Edit profile data
2.Edit contact information
3.Edit bank details.
If information is changed during editing, verification must be carried out again by the head office.
What would the two use case diagrams look like ?
One or two apps?
(Posted before diagrams were added to the question)
Nothing in the narrative says that you need two systems. It's too early to decide about system architecture. You could have the following variants, each with pros and cons:
one and the same system (e.g. post office and customer access it via the web);
one and the same system that is accessible using different components on different devices (e.g. a rich client in the post office, a web interface for the customer on her mac/PC and a mobile app for a customer when using a smartphone);
several independent systems (e.g. a back office in the post-office, and an independent app that would connect not only to the back office, but also to other back-end services e.g. from other companies).
But how do you want to decide before first knowing what is needed and how the needs are related?
First, you have to understand the big picture of what's needed. Focus on the users not on the inner details of your solutions, as explained in the UML specifications:
UseCases are a means to capture the requirements of systems, i.e., what systems are supposed to do. (...)
a UseCase (...) specifies a set of behaviors (...), which yields an observable result that is of value for Actors or other stakeholders (...)
(...) without reference to its internal structure
Look into your narrative to find actors (people, organisation, responsibilities), their goals (what do they need to do?) and how they could relate to each other. Just try a first sketch.
Your current model
(Posted after the diagrams were added)
I still see no reason to go for 2 distinct systems. You are working on a solution for car sharing. It may have different sub-systems/components, but the actors do not care. And neither does your customer. But:
If you'd go for two independent systems, you'd draw two disginct diagrams, and in each diagram you'd have an actor representing the other system that interacts with the system under consideration. As said, this makes sense only if it's an independent system.
In your case, I could imagine this for the bank account verification and the video identity verification: unless you intend to develop your own super-secured AI component capable of doing this, you'd probably outsource this to a specialized company, that may offer this service via an automated API.
The identify verification is at a different level of details than the other use-cases. You may want to show it in a separate diagram, in order not to pollute the main diagram.
And lastly, your second diagram has some issues:
the arrows of extend and include should not following the same direction: the target of an include is the included use case whereas the target of the extend arrow should be the use case that is extended (and not the use case that is extending the normal use case as you have shown).
ID correct and Bank correct are states. Use cases do not show states. The end-state can be specified in the description of the use-case but not in the use-case diagram.
Post office, Bank account, Video seem to be use-cases, but they are not well described.
A possible diagram could therefore be:
Note: I'd personally prefer specialization of Ensure identity. This corresponds more to the reality that there are two very distinct behaviors. But extension is ok.
Just to stress this fact: you do NOT describe a scenario with use cases. A use case is "just" to show the added value a system under consideration delivers to one of its actors. What you are asking is functional decomposition and that's just plain wrong. You would describe a scenario with an activity diagram (or as plain text like in the Cockburn way).
I have an ERP project with multiple sub-domains. It is not using CQRS or domain events.
I have two sub-domains; CRM and Accounting. The customer concept needs to be modeled differently in the two sub-domains. CRM needs to know the size (number of employees) of the company but not the tax number. Accounting needs to know the tax number but not the size. The company name is needed by both sub-domains.
I am thinking of modeling both CRM Customer and Accounting Customer as entities. But then whenever a new customer is created by a CRM user, an Accounting Customer instance also needs to be created. And if a report needs information from both sub-domains, then the queries become more complicated then when you have single entity containing all the information.
Is this the way to go? Is there a better way? Does it make sense to have multiple sub-domains without utilizing domain events?
Are you sure you need DDD? The use case seems quite simple, maybe you just left out all the other complexities, but from just the info you're asking, a simple CRUD app would do. Data Centric apps, like reporting, don't need DDD. You need DDD when you must modify the data in strict ways, to maintain consistency.
If you are sure you do need DDD, then you need to understand the point of the model is to protect against the invariants of the domain. You say a CRM Customer must always have an equivalent Accounting Customer. How is this handled by the business today? How does accounting know about CRM customers? How does accounting know they're talking about the same customer as CRM? However they are doing it currently, is what you should try to model.
As an example, if they do it in real life by just letting the other one know. You could have your CRM context publish a new Customer event, and your Accounting context could react to it by creating an Accounting Customer for it.
If on the other hand, they both learn about it from something else, then maybe they both react to that other something's event.
If you don't want to use events, it could be a direct call, from the CRM context to the Accounting context. Though know that this would grow more restricted as the app grows, but if again you've got a simple domain, its no problem.
Also, querying data is not the same as modifying it. Queries should not use the domain model entities and value objects. It could, but it should not be constrained by it. That's because query is a read only operation. You need to put your data inside your domain model only when you are going to change it.
What I'm trying to achieve is to develop an application implementing the DDD approach.
The story might sound silly but it's an actual, real life problem. Believe me.
The business looks as follows:
Let's say a company specializes in manufacturing sweets which are distributed to its own shops for sale.
The craftsman makes different types of candy depending on what is - and what is not - currently at the display at one of the company's shop.
When a basket of one flavour 'disappears' the seller replaces this type of sweet with a different kind from the shops storage cabinet.
Duplicates of flavours at the display shouldn't exist and the display should be populated with as much as the capacity allows or how much the manafacturer can handle to produce.
The sweets are distributed from the manufacturer's lab's storage to the shop's one depending on the demand.
Let's assume each worker has public view access to the display and the storage cabinet. Each worker (user) decides on it's own what to provide. The shops display view will be publicly accessible through the application to a potential client as an information what is currently on sale.
So far I have split the business logic into three separate (sub?)domains which are:
Production
Distribution
Sale
And of course each entity like Sweets, Storage, Craftsman, it's Repository etc. are placed respectively in their domain.
The concerns I approach are:
Is it appropriate that an entity (Sweet) is being passed from one domain to another?
Should a Provider be able to reach the StorageCabinet of one domain and pass it's content to another?
Is my reasoning proper? Correct me if I'm wrong or violating any DDD rules.
Thanks in advance.
The story might sound silly but it's an actual, real life problem.
This is great, actually. In his recent retrospective, one of the things that Greg Young called out is that "shopping cart" models are a really lousy as a teaching tool. He points out briefly that the interesting questions are in the supply chain.
Is it appropriate that an entity (Sweet) is being passed from one domain to another?
No, but a message (DTO) describing an entity's state might be passed from one domain to another.
You want to keep the flexibility to define the entities differently in each domain; that's part of the point of identifying bounded contexts.
Should a Provider be able to reach the StorageCabinet of one domain and pass it's content to another?
Probably not: your domain model isn't the book of record for the storage cabinet. Listen very carefully to Greg's comments on one way commands.
Pardon the length here...hopefully I didn't go overboard...
I'm in the process of working on my first production MVC application and I'm trying to stick to DDD principles in the process. I've run into some questions related to how to deal with the security requirements of the application and thought I'd see if the SO community could offer some best-practice suggestions.
Domain Information
To use a simplified explanation, this application will have AffiliateCompanies, Users, and Customers.
AffiliateCompanies are hierarchal, so one affiliate can sign up and be tied to the activities of another affiliate. The root is the main company providing the products/services.
Users all belong to an Affiliate entity.
Customers are organizations to which the products/services are sold. Affiliates are assigned to customers such that it is possible for two hierarchically-unrelated affiliates to split a Customer.
Security Information
Rights to perform certain actions in the application will be determined based on an ACL-type of arrangement. Each User object has a property that is a collection of SystemAccessRules that determine what actions they can perform and what the scope of their permissions are (their own objects, their affiliate's objects, or their entire hierarchy's objects). Users can also belong to roles, which themselves have that same collection of SystemAccessRules.
As a result, if a user logs in and wants to see a list of "their" customers, the list could be comprised of customers they are individually assigned to, customers anyone in their affiliate organization is assigned to, or customers anyone in their organization or any of their child affiliate organizations are assigned to.
Database Considerations
DDD aside, at some point the storage strategy has to come into play. In this simple scenario, the tables align with the objects above (including a roles table), with a few support tables to support the relationships between the objects:
AffiliateCustomers - this table allows for a many-to-many relationship between affiliates and customers by storing the PK of each entity as a pair of FKs that are themselves a composite PK for this table.
ACL - this table stores the security information, specifically the subject of the entry (either a user or a role), the action in question (e.g. "CreateCustomer"), the permission (allow or deny), and a scope (their own stuff, their organization's, or their network's).
The Question...Finally
I'm using a combination of repositories and services. I'm trying to keep business logic in the services and out of the repositories or database, but due to the security design here, a simple request for the list of "their" customers could be immensely burdensome, especially as the data set grows. I was trying to use Linq where possible, but this architecture seems not to be very suited. As I see it, here are my choices:
Accept the requesting user as an argument for service methods (or determine it by context), and have the service method populate a list through multiple queries to Linq repository. This would require pulling the list of customers, then iterating through each customer to issue another query to pull the ACL data, then using that data to filter the first list based on permissions. The hierarchy issue would require some fancy Linq footwork (like this), if it's possible at all.
Even if the hierarchy issue could be made to work, it seems like this solution won't perform very well...
Accept the requesting user as an argument, but pass it and the required permission (e.g. "View Customers") to the repository in order to retrieve appropriate data from the database through a stored procedure that would use several EXISTS clauses in a CTE query that could account for the hierarchical nature of the data and the need to check for role and user security.
This pushes a fair amount of logic to the database, which seems very anti-DDD and generally bad.
I'm leaning more toward the second option, but that may be because in my past projects that's how I've done it. I'm not even sure if my design overall is on the right track (in the past the permission declarations were done using bit flags, so it was even easier to do the DB query using bitwise operator).
Has anyone been in similar situations, and if so can you comment on the performance and maintainability of the solution you pursued? I want to stick to high-minded programming principles, but not at the expense of simplicity and common sense.
Have you considered using the specification pattern to pass your business rules down to your data access layer?
The service constructs a specification tree which it passes to the repository. The repository converts the specification into an Expression<Func<Customer, bool>> which it passes to IQueryable<Customer>.Where(...). When the repository materialises the collection, e.g. by calling ToList(), the business rules are translated into SQL and executed on the database server.
Last time I checked, LINQ to SQL didn't support CTEs, so you may need to use a view to flatten the hierarchy.