Model-centric architecture in brief
Current J2EE architectures are challenged when it comes to
maintainability and scaling for complexity and load. The
model-centric architecture answers these challenges by
establishing the pure object model as the central component.
It is based on real world experience and has proven its worth
on several systems now in production.
Being model-centric means to follow seven simple design rules. The
rules are listed below. A more in-depth treatment of each rule is found here.
- 1. Keep business logic as a pure object model at the
server
This provides one location for the business rules and concepts.
It avoids the fragmented and often duplicated business logic
seen in current J2EE applications, which spreads the business logic
over client code, session beans, transfer objects, pure Java objects
and entity beans.
- 2. Partition the model into an operational and a knowledge
layer
Every enterprise application works with a spectrum of business
information ranging from very fast-changing transactional data to
the comparably slow changes of source code. Identifying the pieces
of non-source code information which are not on the transactional
end of the scale provides significant gains in development time,
execution speed and scalability.
- 3. Partition the operational model into edit bubbles
As enterprise object models are larger than the memory of the host,
and as parts of the models are travelling to other vm's, the
hard reference connectivity of the model must always be limited. By
doing this is a systematic way, the system gets easier to understand,
the infrastructure code gets simpler, and the possibilities for caching
increases.
- 4. Use the same model on the client side
Many architectures, J2EE and others, insist that the object model
should not escape the server. This is because they mix infrastructure
layering and business logic layering. While this provides for good
PowerPoint diagrams, it is bad architecture. Partitioning
business logic along infrastructural layers instead of in functional
areas invariably leads to business logic duplication.
- 5. Minimize the touching point between the infrastructure and
the model
The business logic should be as independent of the
system infrastructure as possible. This simplifies, by separating
concerns, and provides for independent change of business logic and
infrastructure. Curent J2EE architectures suffers from the tight
coulpling of business logic and infrestructure
resulting from putting business logic inside session beans and
entity beans, which are infrastructure objects.
- 6. Provide unlimited flexibility at this touching
point
As the interface between business logic and infrastructure is small,
it must be general. A general interface in which all interaction between
business logic and infrastructure takes place allows for some very
sophisticated infrastructure services.
- 7. Remove all unnecessary flexibility (the fear-motivated
flexibility)
Many architectures (including J2EE itself) are unnecessarily
complicated because they put equal emphasis on supporting the rarest
usage scenarios and the most common ones.
By removing explicit support for the uncommon cases, the common ones
can be made much easier and more convenient.
The rules are treated in more detail in
Model Centric Rules.