I have to build an Entity Relationship Diagram and therefore wanted to ask you, if I did it the right way. Any help is highly appreciated!
Here is the assignment:
"Lisa is the owner of the cleaning company CleanAlp. Her company's primary customers are property management companies that manage residential complexes (properties). The customers book one or more services for every property. For this purpose, CleanAlp and the respective customer agree to a contract. There can also be more than one contract for one property (e.g. after termination and new assignment) or temporary additional cleaning services in exceptional cases. Every cleaning service has an interval (e.g. weekly, fortnightly, monthly), which has been agreed to in the contract. A cleaning service refers to a catalogue containing the cleaning services offered by Cleanalp (e.g. sweeping the stairwell, cleaning windows). Lisa employs several people. For each property, one employee is responsible for executing the cleaning services. The responsible person can change during the contract term, but it must be kept track of who and when was responsible. Invoices are sent to customers monthly—the amount to be paid as agreed upon in the contract."
My solution:
Entity Relationship Diagram
Thank you very much!
Sincerely,
Johann
Related
This is an issue we have ran into multiple times now... very much looking forward to others' opinions!
Scenario Description (for illustration purposes):
Somebody visits our website, perhaps they fill out some forms, whatever. To us, this person is a prospect/lead. They have not been fully onboarded as a customer; they are simply a potential future customer.
Certain actions can be performed on these Prospects, such as adding certain data to their profile. Let's call this add_foobar_data. Of course, if they become a real customer (somebody consuming our service), we still need to be able to add/remove said data from their account.
Scenario (tl;dr):
Prospects can become Customers
Mutation add_foobar_data conceptually applies to both Prospects and Customers
Prospects only have a subset of data of Customers (they are a true subset; currently Customers have a lot of non-nullable fields Prospects do not have)
Options:
Create a union type, e.g. Customerable. add_foobar_data would return a Customerable (or backref to a Customerable) rather than a specific type.
Create separate mutations for modifying Prospects and Customers (add_foobar_data_to_prospect, add_foobar_data_to_customer)
Everybody is a Customer! Make all those non-nullable fields on Customer that are not in Prospect nullable and add a new flag called isProspect (or isDraft if we want to change how we think about the flow).
Perhaps some other approach I did not think of...
Anybody have thoughts on what is the best approach to this situation and why?
Ended up using an Interface since Prospect is a direct subset of Customer, and not by coincidence.
I am designing a system for airport as a part of office project and I am supposed to design a class for handling passengers. I am using WPF MVVM so I have my PassengerInfoViewModel which basically represents a Passenger traveling to Airport. I am confused among using State, Visitor and Decorator patterns.
The requirements:
There are several types of Passengers. Passenger can be a *** with SSN + verified biometrics, SSN + enrolled without verified biometrics, Without SSN + enrolled without verified biometrics, With SSN + enrolled without verified biometrics and other combinations with some other entities.
Any of the above passenger can have one of the following status. NewEnrollment, WaitingForVerification, Verified, Rejected, Deboarded, Cancelled etc. The status of the passenger is updated based on some actions performed by airport staff. But this will be updated not during a single transaction. The updated status will be pulled next time a passenger inputs the Booking Reference number.
A passenger can opt for special assistance that triggers a special workflow. The passenger can check/uncheck special assistance during a single transaction. So, the values keep updating in a single transaction. Once the transaction is over, and if the passenger has opted for Special assistance, this can't be changed again.
What I am planning to do is:
Create a base abstract Passenger class which has basic demographic and other details common across all the passengers. PassengerWithSSN and PassengerWithoutSSN can be a separate class with a VerificatonStatus field Verified, EnrolledPendingVerification etc. This will be fetched when initial transaction begins.
Is this right or should I make separate classes for each type (I am thinking so). Reason being each type triggers a different workflow. As the state does not change during a transaction, I am not going with State pattern.
Also, I should be able to plug different workflows per type in future. Workflows involve calling separate APIs and navigation to different pages.
For NewEnrollment, WaitingForVerification etc, this will be put into a PaxStatus and I am planning to use Visitor pattern to handle the logic for this, keeping it out of the main class. Not sure if this is the right approach.
The SpecialAssistance is something which will change during transaction so I am planning to use State design pattern here. SpecialAssistance state and NormalPassengerState Also there might be an Infant state in case parents want to register Infants for workflows.
There are N*N combinations (e.g. a Non-Verified passenger with Biometrics Enrolled and has SSN travelling with an Infant and needing special assistance) which might mess up needing a lot of rework in future if not designed properly.
Can anyone guide me in the right direction?
I've been developing for many years and a common problem I face is how best to separate out the service layer. I've been using the repository pattern mainly, but I still struggle with this common scenario.
Customer service that returns a single customer.
Invoice service that returns a list of invoices by customer.
The consumer of the service sometimes wants just a Customer other times they want the customer and the invoices which is fine to leave as two calls.
But a new requirement may be they want the Customer, but also want the total number of invoices the respective customer has.
I do not want to corrupt the GetCustomer method and do not want to return a list of invoices and have them do a count (this would work). Is there a best practice without getting into create a lot of one of methods while still keeping performance and round trips in mind? I see a lot of designs where there will get GetCustomer, GetCustomerDeepLoad, etc.
thanks.
It's simple. Don't overthink it.
Services need to meet the needs of the clients. If the client wants customer details, the service sends a representation of customer details and nothing more; if the client wants a customer and all their orders, the service obliges; and so on. In doing so, you might need more than just a Customer object; for example, you might need a CustomerOrderList object made up of CustomerOrderItem, etc.
What you MUST NOT do is mix the concerns of order management and customer management, meaning that the CustomerOrderItem that you return will be a version suited for customer management and not the full-fledged OrderItem that would be modelled for order management.
That's the reason why I have switched to CQRS. Operations (writing/commands) often targets a single entity type while reads (queries) often want a composition of entities.
You dont want to get those queries into the repositories as the repositories tend to get leaky abstractions when you do that.
In your case you can have two types of services: Entity services which are responsible of taking care of changes and query services which are responsible of taking care of supplying information to the client (composition of different entities).
I typically use repositories only on the write side and let the query services query the database directly. That works as you have your business logic contained in the entity services.
I'm having a hard time figuring out if Recurly supports a "products as a service" kind of business.
"Products as a service" has following characteristics:
No monthly fee
No charge upfront
Just charge the products itself
A subscription can have different products and different amounts
per product for each customer
The products or (amount of them) can change montly
For example:
A costumer can choose out of products A, B, C and D. He chooses to subscribe to our service and wants a montly delivery of a pack containing product A and 2 of product B.
After three months receiving this subscriptiopn he wants to change his pack. He deletes product A out of his pack and adds product C. The next delivery contains those products.
As far as I understand the API I have the following options:
Create a different subscription per user per "pack"
Seems too
complicated for managing all subscriptions. There will be many
subscriptions created and deleted (set on inactive, as deleting is
not possible). And it certainly isn't intended to be used this way.
Subscription plan of €0,00 with add-ons per product
Add-ons seem to be defined rather fixed when creating the subscription plan. I want my products to be flexible, taking them in and out of the subscription as I please. Doesn't seem to support that.
Metered billing
Also defined as usage-based billing. The proposed use cases in the docs all have a fixed subscription fee (which I don't want). They also add a defined and linear 'product' (eg. 0,1 / minute). Doesn't seem to fit my needs either.
How can I handle this kind of business best with Recurly?
A €0,00 with add-ons per product will be your best path forward. Add-ons are flexible and can be added/removed from a subscription plan as needed.
I'm trying to make the domain model of a management system. I have the following kind of people in this system:
employee
manager
top mananger
I decided to define an User, from where Employee, Manager and Top Manager will specialize from.
Now, I don't know what kind of specialization hierarchy I should choose from.
I can't decide between the following ways:
or
Which might be preferable and why?
As a long time coder, every time I try to do a domain-model, I have to fight against the idea of trying to think in how I'm going to code this. From what I've understood, I should not think about those matters in the domain-model, only in object relationships. I don't have to think of code duplication or any of these kind of details here, so I can't really pick any of the options over the other.
Thanks
EDIT:
I'll be a bit more explicit: This is a program to manage worker's vacations plans. With this program, a employee can choose the set of vacations days for the year. Then the manager might approve or not those days for each one of the employees and at the end of the day the top manager should approve or disapprove the manager's decisions. This is all the users of my program are supposed to be able to do. There are no other tasks.
This mostly comes down to a question of how you define your terms. The basic question is whether a manager can be substituted for an employee under any possible circumstances -- and without knowing the precise rules of the workplace being modeled, it's impossible to say one way or the other about that.
One general notion is that yes, at least up to a certain point, in a pinch a manager should be able to do the job of any of his subordinates (at least one level below, and quite possibly two or three).
On the other hand, in some places with lots of union-driven rules in place, that may not be the case at all. Even if a person is entirely capable of doing a job, rules may prevent him from substituting in that position at all. In some cases this arises from certification requirements and such (e.g., the manager may have one been qualified to do the work, but the required certification has lapsed) or from things like union rules (e.g., a friend of mine who was once reprimanded because he carried a flashlight bulb and battery from the company store back to his lab instead of getting a union materials handler to do that for him).
In real life, Managers are Employees too. So this is surely just a chain of increasing specialisation:
User -> Employee -> Manager -> Top Manager
edit
"This is a program to manage the
vacations plans of workers."
In you company do Managers take planned vacation? Surely they do. And equally surely you are not going to build a separate application to manage that. So what you really need is this:
User -> Requester
-> Approver
Each User will be a Requester in one approval chain. (You may need special arrangements for the CEO). In addition some Users will be Approvers in one or more chains. The final approver will probably vary depending on the grade of the Requester: the CEO won't want to bother themselves with approving the vacation arrangements of the janitorial staff.
You will need some rules to enforce who can be an Approver of any given Requester's holidays. Unless you have an exceedingly flat organisation you will find you have a hierarchy of workers and managers. For instance, a Team Leader or a foreman - individuals who are in other respects "workers" rather than "managers" - may be in the chain. Also you may need to consider other aspects of the organisation. Fr instance, if the employee wishes to carry leave over to the next year that may require approval from the HR dept, somebody who normally has no managerial responsibility for the employee whatsoever.
Edit 2
Okay, so we are modelling an arbitrary set of rules rather than a realistic scenario.
Let's see. Each User fits into a single category, defined by these tasks:
an Employee can Request leave
a Manager can Approval or Reject a Leave Request
a Top Manager can Accept or Overturn an Approval or Rejection
Managers and Top Managers have no behaviours in common. Consequently, the first model is the correct one.
I would model these as actors. They are not the domain of the system, but the users of the system. Would you model a shop's inventory system with 'school-kid who wants sweets', 'school-kid's parent who wants tobacco', 'clerk' etc? Although only a store manager (actor) can give refunds without a receipt, what matters at the system level is that system recognises the store manager's key, and it's that permission token which is in the software rather than role the actor takes.
The domain of the system you describe is vacation requests and the user account, and some of the use cases mean that some of the accounts have permission to perform certain state transformations to a vacation request.
The difference in modelling User/Manager/Employee as actors and roles is that you can focus on modelling what you need to put into the system, as don't have to have hierarchies of actors - you start using abstraction at the use case and system entity levels, rather than in the actors. It's not always a bad idea to think 'how would this work in code', at least as far as asking 'why bother coding this distinction'.