How to incorporate external entity models in conceptual model?

Question

If I want to create a conceptual model for my new application, and during the analysis, I found that some objects like employee, department ..etc are a part of another system. and all the data related to them like employee name or number exist in that system.

My questions here:

• How to handle this case in my conceptual model? Should I include these objects and their responsibilities in my conceptual model?
• How to implement them in my application (Hint: I'm going to use asp.net MVC and EF6 code-first)

Answer 1

IMHO you should model those objects to exactly the degree you need them in your application, no less, no more. For example, don't model all available attributes, just model the attributes which are required by your program. If there is an external entity where you need only one or two attributes in your system, you may consider to add those attributes to an existing internal entity. If you need more, consider to model the external entity with the required attributes, but try to keep naming identical or at least consistent.

This is valuable information for implementing the code of your application. If you would exclude the objects from your model, writing a cohesive description would become much harder.

If you think it is helpful for the audience of your conceptual model, use a consistent way of tagging the entities or attributes as external entities. For example, in UML you could introduce a special stereotype for this. Or you use some kind of comments or annotations, depending on the notation you are using for your model.

Later, when you are going to implement this, you will probably need some kind of proxy-like objects for accessing the external entities, containing exactly the attributes you modeled above. So in this sense, the objects are also part of your system, at least to a certain degree.

How you implement them exactly depends heavily on the details. For example,

• if your system needs only read-only access to those external entities or also write access,

• if there are immutable keys in those entities which allows your system to create references (or not),

• if there are some inconsistencies tolerable between the proxies in your system and the external system (at least for a certain period of time)

• what kind of API the external system provides

Depending on such details, you may decide between

• implementing proxy tables for those objects with some kind of synchronisation strategy, or just

• implementing them as database views, or

• with no database representation at all, just by pulling the attributes into your client objects using some code.

Answer 2

OK so! your application is a "shift management app"

In essence this app doesn't really care about employees and departments. It will care about when the business day starts and ends, how many people are working at the company, how long a shift is etc.

So you should exclude them from your conceptual model. It will only complicate it. Perhaps for example, sometimes a shift is not filled by an 'Employee' as defined by the other system. Perhaps its a contract worker or some such.

Create new models for the object you do need Shift, Person, BusinessDay etc and describe the system in those terms.

When you actually come to make the system use those same objects, so that it is flexible enough to work with any data, but link them up to the other systems with a separate export or mapping layer.

For example. Imagine instead of writing your own Shift Management App you have decided to buy one 'off the shelf'. You wouldn't expect the off the shelf app to be able to connect directly to your existing employee models. Its got to be able to work with many possible sources of data.

You would however expect there to be an API or Import/Export function that would allow you to link your existing systems to it. Using your Employee data to populate its ShiftWorker data.

Writing your own in house product will allow you to tie the two models more closely than an off the shelf product would. But you should still respect the separation of concerns between the two systems and provide a Mapping or Anti-Corruption Layer abstraction between them.

Answer 3

I believe that the answer from @Ewan covers the specific scenario provided, so this will follow a more generic/general route, where possible. (Note that the below examples are only used to show a similar perspective)

The first thing that comes to mind to help with your confusion is to show some relatable issues seen when dealing with differing namespaces, for this case we can look at enums. For instance, if we have an object in some data layer to act as a "Master" enumeration that defines the typing for a given entry. (EX: PersonEnum { Employee = 1, Manager = 2, Contractor = 3, CEO = 4, Vendor = 5, ...})

When coming up to some use case, there could be an instance where an enum (ValidPersonEnum) is defined to state which of the PersonEnum values are valid for the use case. For example, employees and managers can only be shown in a salary report, contractors can be shown in both salary report and project cost summary, and vendors on show in the project cost summary.

When checking these values against each other (is the given entry of the type Employee?), an error occurs, where the namespace is used to define the type of the enum. With this in mind, we can approach a high-level standpoint using your example.

For the external system Employee, it is defined within that system as part of its concept. For your system, you can use Employee, via data or methods, but that Employee is essentially changed to YourSystem.Employee rather than ExternalSystem.Employee.

For your model, Employee could then be shown in respect of how the current application uses it rather than how the external system does. To branch on @Ewan's point, this confusion could be cleared up via some form of abstraction. This could be used in your application as a concept of Person as a base, and Employee as some implementation of Person.

With being general, I would like to note that there can be times, where you would/could want to include the concept from the external system. These would fall more under extension type applications, where the new application will manipulate (create/modify) data within the external system.

So for your first question, you would not necessarily be stating the responsibilities of Employee in respect to the external system. Employee should be stated for its responsibilities in your model, and there could be similar methods depending on what is needed. This model would then be in respect to the target application. If you tried designing the model around another system, then it may end up looking more like an addition to that existing system rather than a separate application.

Also, if a model depended on how an object is used in a separate system, then it could become more difficult to get some new applications off of the ground, since the object(s) can change at anytime for any reason(s) outside of the new application (during and after designing a concept model).

If you decide to state the data source of each item, then you could include the path (file, database server, etc.) or some named process dependencies (nightly refresh or some other external data processing).

As far as the implementation question, this is where you have different levels to review. The concept will give you a road map for your application (X class holds a list of Y class to determine if action Z can execute, or M class cannot exist without L class). When implementing the concept, the data source can be defined, since the concept may not have the opportunity to have defined a source. These implementation step(s) would end up being the place that defines the interactions with other systems (Employee data is retrieved based on the external system).

Again, the above examples were only given as an attempt to show a similar perspective, and I think @Ewan's answer covers the same points in respect to your example. I hope that my examples help bridge the provided concepts.

Answer 4

Those entities are not really yours and can be changed outside of your "system" but you can provide linkage to them.

For example, here is your Employee model entity (which will also be the EF code first class):

public class Employee
{
    // Your key and anything else besides whatever the external entity provides
    public int Id { get; set; }        

    // 1-to-1 relationship to the external entity
    public virtual ExternalEmployee ExternalEmployee { get; set; }
}

And here is the ExternalEmployee model entity (and code first class) which provides you with whatever properties you want from the external entity by mapping to a database view (see the DbContext below):

public class ExternalEmployee
{
    public int Id { get; set; }
    public string Name { get; set; }

    // 1-to-1 relationship to your Employee
    public virtual Employee Employee { get; set; }
}

The EF DbContext (vw_ExternalEmployees is a database view providing all data to ExternalEmployee):

public partial class MySystemContext : DbContext
{
    // ...

    public virtual DbSet<Employee> Employees { get; set; }
    public virtual DbSet<ExternalEmployee> vw_ExternalEmployees { get; set; }
}

Your EmployeeRepository is responsible only for your Employee, of course. As a consequence, in your service layer (e.g. EmployeeService) if changes need to be made to the external data they must be delegated to the corresponding services responsible for the external entities.