Freigeben über

Is an entity service an 'antipattern'

  • Artikel

I've seen many folks who have come to the conclusion that CRUD services (aka 'Entity services') are an antipattern.  Most recently, Udi Dahan asked me if I felt this way.

Hmmmm.

I have an interesting job at the moment.  While the Enterprise Architecture team in Microsoft has been primarily focused on Governance, a project in the team that I was 'assigned to oversee' really needed an architect, so the Vice President of IT personally drafted me into that project.  (I consider that an honor.)  Unfortunately, it means I have two jobs (at least for now, but movement is coming). 

  • One job: look at the Enterprise... what is right, and what is composable and where does business agility lie. 
  • The other job: look at the problem space in an enterprise system: what is decoupled and what is interchangable and what is less costly to own.

And that is why I am slow to dismiss Entity services. 

Because, as long as we are not sharing an entity service outside of a fairly tightly constrained 'area', I have no problem with creating an entity service and composing two or three activity services out of it.  I wouldn't share the entity service beyond that tight space.  I may still want to intermediate, but primarily for operational things like end-to-end transaction tracing and uptime monitoring... not to add logic.

The benefits of an entity services are all about decoupling.  I can create an entity service on a single business entity off the data in one application, and then, as the business moves to another application, I can create another entity service with the same interface.  I will STILL have to change my activity services (I'm not a fool), but hopefully I can minimize the change and therefore reduce the cost of change.

I cannot come up with an example of using an Entity service based on 'integration' because I cringe at the notion.  If my order management system wants to create a customer in my relationship management system, I will NOT use a CRUD service.  On the other hand, if my order management system needs to present a couple of different 'activities' to the world, I might stand up an entity service 'under the covers.'  'Assert an Order' (idempotent create) and 'Cancel an Order' (idempotent delete) are both Activity services.  They may both use an 'Order Entity' service, for example, that is not visible to the enterprise but is still used to compose the activity services.

So, is an Entity service an antipattern?  From the enterprise perspective, yes.  From the application perspective, no.  (these are not in conflict).  I guess it depends on where you stand.

Comments

  • Anonymous
    May 24, 2007
    I totally agree! Pingback from http://soa-eda.blogspot.com/2007/05/two-worlds-of-soa.html

  • Anonymous
    June 06, 2007
    So, if I'm understanding you correctly (and please correct me if I'm wrong here), Entity Services belong in the Application Architecture domain. They are not part of the primary level of decomposition of SOA. The top level Service (big S if you will) is the one that receives messages from other Services, and it could then forward (or translate) those messages to an Entity Service. In which case, we can have a discussion about the relative value of Entity Services over things like Domain Models. I think that there's a lot of value to be had there. Your thoughts?

  • Anonymous
    June 06, 2007
    Hi Udi, I agree with your comment.  Entity services are in the Application Architecture domain IMHO.  If you present them outside the application, as a point of integration, you do yourself a disservice. I do like the idea of using entity services over domain models because it takes some of the compromises we make for relational data storage out of the system.  I don't know if this applies all the time, but when it does, I think it's a great use of Entity (CRUD) services.

  • Anonymous
    June 11, 2007
    Studying up on enterprise service design and following your blog for a while now. You always seems to provide interesting subjects for me to dig deeper on. In your discussion with Udi, are you guys "OK-ing" the use of consolidated entity services at the enterprise level? For instance, if we expose CRUD services specific to an application at the application layer, and then expose another sort-of "master data management" layer to the enterprise which provides those entities to other applications for interface purposes? This layer would hide the implementation details of the application domains? Am I on the right track here?

  • Anonymous
    June 12, 2007
    Hello David, Normally I would not agree to providing CRUD services to the enterprise.  You bring up Master Data Management, and I'd like to cover that seperately. There are two needs: sharing "outside" a solution domain and sharing "inside" a solution domain.  A solution domain is an arbitrary boundary that you use to group the applications in your infrastructure.  The applications that fall into the solution domain are collected there because they share the data elements AND one or more of the features needed to manipulate them.  So, of your organization has two CRM solutions, one for the sales force and the other for the call center, then they would fall into the same solution domain, even though they would typically be different business groups. Master data management within a solution domain is done to synchronize data.  The goal of this aspect of MDM is to create a 'single version of the truth' that can be used downstream in Business Intelligence as well as in process simplification and consistent user experience.  At this level, it is OK to share CRUD services because you frequently have to coordinate an insertion in one data store with an insertion in another. Master data management outside a solution domain is an entirely different story.  Each solution domain owns an aspect of the enterprise data, and outside the domain, you can either perform a read-only request (against a REST or WS service or an exposed cache or a distributed cache using SSIS, for example), or you can perform a 'request to change master data' which is an ACTIVITY service (or higher), not an entity service.  In other words, significant business logic will be required, and many data sources may need to be checked and or coordinate.   That level of service is appropriate to expose to the enterprise.  It's on the edge of master data management, in that you have to insure that other systems adopt this mechanism and drop all direct database links and CRUD-style entity service connections. Alas.... we can never get far from SOA governance.

  • Anonymous
    June 21, 2007
    Nick, I sincerely appreciate your response.