Concerns about anemic data model

TL:DR; Are contract objects in a service oriented architecture an indication of an anemic data model, and therefore an issue/liability/code smell?

Background Info/Structure

After about 5 months of planning, strategy, and "visions", the rubber is starting to hit the road for my projects at work. Its a greenfield project, so no legacy code to worry about, but since this is predominantly an integration project, there other systems to think about.

The systems at play are the accounting system and a "pipeline" system for tracking new business. The system I'm developing will exist as an intermediary between the two and perform any business logic needed for the translation (a service broker, if you will). The pipeline system needs to understand the business in the accounting system and the accounting system needs to know about closed deals from the pipeline system.

Both systems are external to our environment. The pipeline system has APIs to cover our needs. The accounting system had two options; a "roll your own" API, and VPN access to the database. Due to the api being orders of magnitude more expensive than the VPN, we went with VPN access.

There is one server (plus my dev box, but that's not important) that is connected to the VPN. The web server that will be central to all of this is on a different server. This was a requirement on IT that only the VPN access and web access were on separate machines, and considering how the web app will likely grow beyond just this integration, that requirement is fine with me.

So that means I've got a self-hosted Web API service responsible for pulling the data out of the accounting system. The export will get kicked off from the web server, which will call that service for the accounting data, perform a bit of business logic on the returned objects, then post the final data to the pipeline API.

Anemic Concerns

So here enters my concerns about my anemic data model. I currently have a separate "contract" project that contains the objects necessary to pass the data back and forth between the different services that I have. It contains enough to serialize itself properly, but that's about it. The design of the objects are currently dictated by the portfolio API as that's the only piece that's already in place. Also there are no other business concerns for these objects at the moment, just the communication for this integration.

I know that anemic data models are considered an antipattern by people such as Martin Fowler and by Domain Driven Design (which I've started to read up on, but haven't gotten very far with). Some of what Fowler is warning about, behavior/actions that are most likely the responsibility of those objects being done outside of those objects, are things that I'm already seeing within my code. Of course there are others who say that either an anemic data model isn't actually a problem or that its only a problem in certain cases and is just fine in other cases.

My two questions are whether or not it matters in this situation? and if it does matter, then what's the best way to solve it?

As I see it, the current organization serves a purpose, and minimizes some duplication. Each side component I'm developing has different functionality, which would should be encapsulated within its own object anyway, what difference does it make if the objects that are responsible for that functionality are not tied to the objects that contain the data. As far as the application expanding in terms of scope, the idea would not be for these contract objects to be the basis for any sort of domain model, so it the anemic nature of these objects would not necesarily mean that the model for the entire application would be the same.

The other side of the argument is that there are 3 objects (the contract object, the functionality within the accounting service, and the functionality within the web application) where there should be 2 (the functionality within the service and the web app, each with roughly the same data in each object). And the objects in the second arrangement would more clearly object oriented (with the objects encapsulating both data and behavior) than the first arrangement. It would also be a potentially benefit to shield the changes to the pipeline API from the communicating with the accounting service (which maybe hints that the two are perhaps too tightly coupled in the current arrangement).

Would it potentially be useful to have a common interface between the two that expressed the exchanged data, as a way to make it easier to pass the data between the two types of objects back and forth?

Any thoughts, impressions, concerns, criticisms, or suggestions would be greatly appreciated.

by ThereKanBOnly1 via /r/csharp

Leave a Reply