Skip to end of metadata
Go to start of metadata

Enterprise POJO is not really a term, but we have coined this term to have a starting point of a discussion on the topic of weather there are differences between application objects (POJO) and the objects we use in enterprise development.

Quite few of the objects in a typical application will be Enterprise POJOs. Most objects of will be private to one application. But the objects that are shared between two applications and the objects that are shared across a large number of applications in the enterprise must be treated differently. The fact that more systems depend on the same objects means we have to deal with a lot more problems. "Enterprise POJOs" is a term we use to discuss these issues. An "Enterprise POJO" is an object that is being used by (many systems? more than one system?) in the enterprise.

For Enterprise POJOs, dealing with change is the most important issue. Changes will affect many system, and the systems might want to adopt these changes at different times. Simplicity, understandability, etc will have to be sacrificed in order to support change across multiple system.

As enterprise systems are long lived, an important source of savings comes from identifying systems that can be taken out of commission and no longer maintained. The problem of many interoperating systems often means we need to introduce indirection layers. However, each layer of indirection will make it harder to identified information that is no longer needed.

Prioritized feature POJO (Fowler et al) Enterprise POJO (#GeekCruise)
1 Understandability Modifiability
2 Simplicity Understandability
3 Modifiability Simplicity AsSimpleAsPossible

The reasons why we have a change in the prioritization for enterprise POJOs are

  • They are by default remote (By this we mean that their common characteristics is that they are used across system boundaries, not that they necessary extends serializable or provide remote proxies)
  • They have more external dependencies. (parts, systems, applications)
  • They are exposed to extreme frequent changes in the requirements (world around them changes more frequently than the application itself.)
  • They need to support non-deployment changes/updates (which has never been simple).

So the enterprise POJO is a contradiction in terms, as an enterprise POJO will never be able to actually be implemented as an POJO

Some discussions

Q: Is really combining state and behavior (as in OO) a good idea for evolvabillity?
A: As you change the behavior of an object, you explicitly introduce a data-migration process on the state of the object, and it does not seem as a sensible idea to move to a more loosely coupled strategy. What might be in sight for the future, is a mechanism to explicitly add the transition-of-state concept as a language feature.

Q: What about EJBs, Hibernate-objects, Domain-objects?

glossary glossary Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Sep 21, 2008


    • wont work.... need to split the object down to smaller-parts (mixin style) and apply a multi-understanding transformation on both sides of the system boundary..
    1. Sep 21, 2008

      By "versioning" I mean that a service (or service aggregate?) must at the same time support clients which use different versions of the API. There are many implementation options for how to achieve this, and I expect that you say "versioning" you mean one of these implementation options.

      Mixins might be a good way of implementing support for multiple versions. Is this the time to discuss implementation of this, though?

  2. Sep 21, 2008

    what this shared behaviour and state is really not an object at all... and we might be better og by coining a new term for this "thingy.."

    1. Sep 21, 2008

      There might not even be shared behavior. And the state at one system will probably be a subset of the state at another system.

      1. Sep 21, 2008

        if there is not shared behavior - there will be duplicated behavior -> which is worse?

        1. Sep 21, 2008

          shared behavior <--- no joke

          1. Sep 21, 2008

            duplicated behavior ==> inconsistent business rules ==> max 3 year lifespan..