Shemazar

I have a system where I have multiple domain models, call them A and B. A and B are similar, but not the same--the interfaces are different. They were both designed for the same general functionality.

I am working on a project where we want to present a common UI for a specific workflow for both systems, without changing the back-end transactions already in place for both systems. The workflow is common to both systems (same general process), but the models are different. Is there a general pattern for handling cases like this

From what I'm thinking, the MVC architecture behind the scenes are going to be very messy. I'm not clear on how something like this can work, since it seems to me for a UI to work, it needs a common/stable model to interact with--not two different ones with different interfaces. (of course, unless you develop a UI to match the interface of both systems)

Any thoughts


Re: Architecture General Supporting Multiple (but similar) Domain Models?

Ollie Riches

my first thought is why do you have multiple domain models for the same general functionality

This breaks the idea of unification in DDD and leads to lots of problems and confusion.

Ollie Riches






Re: Architecture General Supporting Multiple (but similar) Domain Models?

Shemazar

Short answer: merger between two similar companies, you have a lot of duplicated systems with a similar, but not necessarily the same domain model. There could be jurisdictional differences, etc.




Re: Architecture General Supporting Multiple (but similar) Domain Models?

Cristerpher

There are two things that I would do, one short term and the next long term:

1) Implement a Facade layer inbetween your domain and ui layers that is responsible for selecting the appropriate business logic to use. This will give you a consistent API to use in your UI.

2) Merge your domain models--abstract common functionality, combine classes that do the same thing, create a unified business model. You can do this in phases and all you have to do is update your Facade layer as you go without affecting the UI.

Does that address your issues

Cris





Re: Architecture General Supporting Multiple (but similar) Domain Models?

Martin Platt

Shemazar,

I would ask how much commonailty is there between the two systems, or companies in this case Since we're talking about two existing systems in production it makes a big difference to what is available to you as a solution.

Is there enough to enable you to abstract an interface for them both, so that the data can be presented in a generic manner If there is too many special cases, then it might not be worthwhile, as you'd end up effectively writing two applications that effectively are accessed through one application.

If there is plenty of common functionality available, and most differences are in business rules specific to a particular company, then it might be possible to use a factory to create the actual objects for each system, and return them through the same interface. It's really down to coercing both systems into one broker of objects, where the objects can be seen by the UI as the same.

If there is only a small portion of the system that is system that is shared then, assuming that you have the source for the systems, arguably it might be better to create an area that shares this information, and an application that sits over that, that each system may use. Then each application can utilise that shared data, and/or functionality. I guess that's down to how those models intersect, and the work involved to produce the solution.

I hope that gets you started, since I think that the answer lies in a number of factors regarding the systems that you have. Things to consider are how well they are written; are they decoupled such that they can easily be consumed outside of their native applications

From what I'm reading, the process is similar, but the models of the systems are different. That means that you probably have some form of shared workflow, is that correct Does that shared workflow also depend on data in the models that could be abstracted I think that you really need to ascertain whether it is worthwhile, or indeed possible to combine these two products first, then approach how you go about it. It might be that the best thing to do is to change the logo on the products, and launch them from a common UI, for instance.

I hope that I have given you a few places to look, and a few things to consider, to help you along your way,

Good luck,

Martin Platt.






Re: Architecture General Supporting Multiple (but similar) Domain Models?

Ollie Riches

Personally I would consider selecting a single system and then analysing the benefit vs. risk on merging the data into the single system using ETL process or something similiar. I know this can be complicated and time consuming, but nothing compared to the confusion and management need to maintain two different systems with two different development teams etc...

HTH

Ollie Riches






Re: Architecture General Supporting Multiple (but similar) Domain Models?

LivetoCodeCodetoLive!

I definitely think you should have only have one data layer, but you can have different views of the data to fit the requirements of the data consumers. You can even retrieve the data and map the data objects to your business objects in each business domain.

But definitely, 2 separate data sources is not the way to go.






Re: Architecture General Supporting Multiple (but similar) Domain Models?

Shemazar

"If there is too many special cases, then it might not be worthwhile, as you'd end up effectively writing two applications that effectively are accessed through one application."

This is what scares me.

Of course I'd like to be working from the same data layer. However, because the interfaces for the similar parts are different for both systems, I'm not clear on how I can implement a solution whereby I might be able to use a factory to create the actual objects for each system through some common interface. I guess I'm thinking about the details of how to implement something like this vs. the high level application. I originally thought about an adapter layer, but that didn't seem to fit the bill because I am not wanting to adapt one interface to another.






Re: Architecture General Supporting Multiple (but similar) Domain Models?

LivetoCodeCodetoLive!

Basically you use a different namespace for each system e.g. Accounting.Customer, Sales.Customer, and your factory returns the object that you instantiate with it's fully qualified name.

Am I making sense or is this different than what you had in mind






Re: Architecture General Supporting Multiple (but similar) Domain Models?

Shemazar

Using your example, the Customer object is coming from two systems (Accounting & Sales). However, to work with either one from a single UI implies that their interface is the same, unless the UI is knowedgable regarding two different types of customers. In your example, I envision something pretty standard like:

CustomerFactory
+ getCustomer(string type) : ICustomer

But from my perspective, I see something like this, using your example:

IAccountingCustomer
ISalesCustomer

Basically, IAccountingCustomer has a lot in common w/ ISalesCustomer, but they have their differences (no doubt, because they are from two different systems). The UI I'm trying to develop should allow for a view of the customer (it could be IAccountingCustomer or ISalesCustomer), and all the functionality for the existing systems must be preserved. So I'm not certain I can use the object factory like you are discussing, because technically speaking (literally) I need to know which interface I'm working with to be able to perform certain things and look at certain data for the respective systems. Am I thinking about it in the wrong way This is for two large systems, so I'm seeing this getting messy and ugly fast.

Am I overthinking it, or thinking about the problem in the wrong way







Re: Architecture General Supporting Multiple (but similar) Domain Models?

LivetoCodeCodetoLive!

It would be easy to know if the type was IAccountigCustomer or ISalesCustomer (e.g. by using Typeof() in C#).

Secondly, I think you definitely need to have a look at the web service software factory here. This will get you started on your way.






Re: Architecture General Supporting Multiple (but similar) Domain Models?

Udi Dahan The Software Simplist

You might want to look at the Naked Objects pattern, allowing users to work directly with the domain objects. By using reflection based technologies (consider the PropertyGrid), users would see all the specific data of each object and could update those fields directly. That object could, in turn, kick of the specific workflow for its domain.

Does that make sense