Azure Service Fabric Application Design - service-fabric-stateful

I have a couple of stateful services in my Azure Service Fabric application. Both of them are related to each other, something like Employees & Departments through a common Key.
Employee has a departmentId to identify which department they belong to.
Department has employeeId to identify what all employees belong to that department.
In the GetDeparmentEmployees API call (from Stateless service), I need to provide the information about the department (e.g. Function areas, who is leading the department) and employees (e.g. Employee Name, their role in the department).
Both the objects Employee and Department are stored in 2 separate reliable collections.
My question is about design best practices.
I have an Employee contract in the employee service and currently stored in its own reliable collection.
I have an Department contract in the department service and currently stored in its own reliable collection.
Do I have to create a seperate Employee contract in the department service, get the data from Employee reliable collection for that department and map it to the newly created Employee contract?
Or should can I create a common Employee contract and use it across both the services?
Although, the 2nd one seems to go against the principles of microservices (no shared libraries), first one seems like a lot of redundant work. (e.g. I may want to pull the personal information about the Employee in the future)

Related

How to design an address table for houses and apartment complex

I want to create a table which stores customer's addresses for a servicing company.
Some customers have a home address, while others have ana apartment, and service contracts include whole complex service contract.
How can I approach this design without redundency in apartment complex based addresses where only the flat number is different.
It is worth it to make a Many to Many kind of reference between two tables? e.g. : tblCustomer, tblAddressdetails, tblAddressUnit.

When to use Core Data relationships in Swift?

I've read through a bunch of tutorials to the best of my ability, but I'm still stumped on how to handle my current application. I just can't quite grasp it.
My application is simply a read-only directory that lists employees by their company, department, or sorted in alphabetical order.
I am pulling down JSON data in the form of:
Employee
Company name
Department name
First name
Last name
Job title
Phone number
Company
Company name
Department
Company name
Department name
As you can see, the information here is pretty redundant. I do not have control over the API and it will remain structured this way. I should also add that not every employee has a department, and not every company has departments.
I need to store this data, so that it persists. I have chosen Core Data to do this (which I'm assuming was the right move), but I do not know how to structure the model in this instance. I should add that I'm very new to databases.
This leads me to some questions:
Every example I've seen online uses relationships so that the information can be updated appropriately upon deletion of an object - this will not be the case here since this is read-only. Do I even need relationships for this case then? These 3 sets of objects are obviously related, so I am just assuming that I should structure it this way. If it is still advised to create relationships, then what do I gain out of creating those relationships in a read-only application? (For instance, does it make searching my data easier and cleaner? etc.)
The tutorials I've looked at don't seem to have all of this redundant data. As you can see, "company name" appears as a property in each set of objects. If it would be advised that I create relationships amongst my entities (which are Employee, Company, Department), can someone show me how this should look so that I may get an idea of what to do? (This is of course assuming that I should use relationships in my model.)
And I would imagine that this would be the set of rules:
Each company has many or no departments
Each department has 1 or many employees
Each employee has 1 company and 1 (or no) department
Please let me know if I'm on the right track here. If you need clarification, I will try my best.
Yes, use relationships. Make them bi-directional.
The redundant information in your feed doesn't matter, ignore it. If you received partial data it could be used to build the relationships, but you don't need to use it.
You say this data comes from an API, so it isn't read-only as far as the app is concerned. Worry more about how you're going to use the data in the app than how it comes from the server when designing your data model.

How to model: Team <-(1) --- (N)-> Employees, with a twist; Better Pattern?

I have to model and create in a SQL Server database a simple relationship...
A Team can have zero or more Employees assigned to it; An Employee can only be assigned to a single team. Simple enough... Here is the twist that I am struggling with...
The Team has a TeamLeader, who is an Employee. A TeamLeader can be assigned to a single Team. So, I added the TeamLeaderId long to the Team and gave TeamLeaderId a unique index. I created a foreign key relationship between the TeamLeaderId in Team to and EmployeeId in Employees.
Is this the best model for this situation, or is there a better pattern?
Thank you for your help and guidance,
Mike
For the constraints you laid out this looks right. But it seems you would be better off with a link table between Team and Employee. Why limit an employee to a single team or make it mandatory for an employee to be in a team at all? Today someone (you?) may think this is the only way, tomorrow it may be different.
It is better to remove TeamLeaderId field from Team table and create new table TeamLeaders (with an unique key [EmployeeId in Employees + TeamId in Teams])
Now, you can change your mind and remove team leaders from your business domain model without pain: just drop teamleaders table.
I think the answer to this question depends much on the usage of the system:
If the Team is created and employees assigned, and then finally the team leader is chosen among any of the team members, its a good choice you have made.
On the other hand, if an employee is hired as a team leader, and he will always be assigned as a team leader it is better to add this "type" of information to the Employee table (othervise adding/removing an employee requires extra uneeded logic to handle the TeamleaderId and potential future "types").

Silverlight4: Loading 2nd level data from RIA Services domain service in many-to-many scenario

I have the following database structure:
Children --> Gifts <-- Possible_gifts, where the arrow denotes 1-to-many relationship, i.e. "Each child can have many gifts and each one of those gifts is one of the Possible_gifts." (forming the classical many-to-many relationship). Possible_gifts table includes (among other things) the names of the gifts, the Gifts table only has the ID of the Possible_gift, the ID of the child and some other necessary data (like date, etc.)
Now in the Silverlight client I need to get not only the Child and Gift data from the domain service, but also the Possible_gifts table data (mainly the name of each Gift that is associated with the selected Child). I tried:
return this.ObjectContext.Children.Include("Gifts").Include("Gifts.Possible_gifts") as suggested somewhere else, but it doesn't work.
Does anybody have an idea how to solve this?
Thanks.
Discovered where the problem was. I was missing an [Include] attribute in the metadata class of the domain service. It turns out that having the above mentioned code in the domain service alone doesn't do the trick!

Domain Modeling or class diagram for car dealership

I am trying to draw a domain model or class diagram in UML for car dealership. I am stuck with how to present test drive in the model. One way is to have appointment class and then test-drive as sub class. A dealer also offers after-sale vehicle service so i could have appointment/booking class as super class and then vehicle service and test-drive as two sub classes.
Another way is to have the customer class have a direct relationship with test drive class and vehicle service class under appointment class.
A dealer also sells new and used cars and their parts.
A dealer also offers finance for car sale.
Would testdrive class have relationship with vehicle class or there is separate class for display and testdrive class?
Another question is how do I show potential customers and their inquiries about sale and service in the model. A dealer wants to save details of potential customers if they allow for marketing purposes. Shall I have two classes: one for customers and one for potential customers or it can be achieved just by using an attribute in customer class?
You can really only distinguish the right decision by having a good set of use cases or expected behaviors of the model.
This will inform whether a particular sub-classing is really accurate.
I can see that an appointment might contain several test-drives, which are themselves linked to individual vehicles, So a test-drive itself is nothing more than a link from a customer to a vehicle which are linked to an appointment.
test-drive would contain the information relevant only to the test-drive:
reference to the customer - even this might be debatable to include
reference to the vehicle
length of test drive
location (perhaps the vehicle was driven at a different location than could be determined from the owning appointment)
customer temperature (hot or cold - i.e. did the customer seem enthusiastic)
comments
etc.
But what is not in the test-drive object is anything related to the appointment - since it is always contained in a collection - possibly as part of an appointment or some other event container. Now if the containers which can contain test-drives always include customer information, I might not even include the customer reference in the test-drive object - after all, it will be redundant.
It depends if test-drives can occur in non-appointment scenarios - perhaps at a "sales event" or an "open house" or something where appointments are not actually created in the use cases - or if test-drives for multiple customers will occur within a container.
The second part of your question has been forgotten (easily done when you ask two questions in one):
Another question is how do I show potential customers and their inquiries about sale and service in the model. A dealer wants to save details of potential customers if they allow for marketing purposes. Shall I have two classes: one for customers and one for potential customers or it can be achieved just by using an attribute in customer class?
I think your use case there is "A dealer wants to save details of potential customers if they allow for marketing purposes." and the simplest solution is to have a Mailing List collection which holds name and address of each potential customer.
I think you miss the point. The aim of the domain model is make famliiar you with the domain:
-- What kind of entities you have in yor domain?
-- If they are important for your system under desing,
what kind of properties they have, how they behave?
-- What kind of business rules they obey?
The rest is details. Think like a map maker. Record what there is.Create a simple map so you can not lost your way in that domain. Not try to invent.Abstract what exist in the domain: Not run behind the "fancy abstractions" you created yourself.
Domain model can be used as a source
for object oriented analysis/design.
But their aim is not to represent
software abstractions.