Joshua Chini

Tags: PersonService

At my company we have a service which provides information about all employees. The service has only one table and returns either a single object representing an employee or a DataTable containing information about one or more employees. The service gets it’s information from our HR system. The service allows you to specify which fields you want so that you are not transferring unnecessary data across the network. For example if I have an employee Id and want their Name and JobTitle then I can pass the employee Id as a filter and get back an employee object which has a collection of name value pair items containing just the Name and JobTitle. We have hundreds of applications making millions of calls to this service daily. This works great as a service for employees, but what if I wanted a new service which contained information about every person our company interacts with not just employees. This could include vendors, visitors issued a badge at the front desk, customers, etc. We have hundreds of systems containing a variety person data and it would be nice to pull all that data into a centralized data source and provide a service to query it.

This person service is going to be the system that I focus on for the next few blog posts. I will be iterating over the design as we go and I will be incorporating a number of newer technologies that I have been wanting to learn more about. I try to be pragmatic about my design decisions and so if one of the technologies isn’t a good fit then we will pivot and choose a different path. Here are some of the technologies I want to evaluate for this project.

Technologies

• GraphQL
• Entity Framework Core
• .NET Core
• .NET Standard
• ASP.NET Core
• HangFire

You may recognize some of the technologies from the list if you have read any of my previous articles. I have been thinking about the design for this system for a while now and have been performing spikes to determine the feasibility and impact of certain design strategies. I believe that spikes should be done as early in the design process as possible to reduce the impact if you have to pivot and go a different direction. I also believe that spikes shouldn’t be done in the core solution meaning that the spike should be built in its own solution allowing it to be evaluated on its own merits and not building up technical debt that must be later cleaned up in the core solution. If you haven’t read my earlier posts here is what I have covered so far.

• HangFire
• EntityFramework Core – Getting Started and Diagnostics
• .NET Core and .NET Standard

I have performed spikes on GraphQL and ASP.NET Core, but haven’t written about those efforts yet.

Now that I have described the system I am going to be building and some of the technology choices in the next post in this series we will look at the domain model.