SOA is a technical architecture, Evans
DDDIs the philosophical methodology, the direction is different, or the two are very irrelevant. Even in two different directions. Use
DDDThe system can be built from scratch to large, and to a certain extent, you need
SOA, integrating heterogeneous. If you say
DDDAnd
SOAIf there is any connection, then the component Componen may be the bond between them. The following analysis of these concepts below, please discuss the improper.
SOA Concepts
SOA is a high-level architecture that uses EJBS to
DistributedComponent will not be considered after
SOA, with DCE (distributed Computing Environment), CORBA (Common Object Request Broker Architecture), DCOM (D istributed Compone NT Object Model) or Ejb/rmi (Remote Method invocation), etc.
DistributedArchitecture experience, transition to
SOAis an easy concept, otherwise, without such a scalable architecture concept, SOA is particularly difficult for them to accept and is a very steep learning curve.
Many people in the current domestic database-centric software thinking, did not realize that the database is not
Elasticity ofTo get them to accept
DistributedComponent concepts are difficult, let alone
SOA, which is
SOAShouting for so many years in the country, there has been no large-scale application of reasons,
SOA and EJB As for some people very high-end, accept not overnight, nor I write two articles the database is dead can accept. This is a matter of overall quality and level.
One
SOAArchitecture
SOA is a highly granular architecture for business reuse, a coarse-grained service, and an ESB is a conduit for communicating between these coarse-grained services, an ESB that communicates services to each other, and is a service-oriented architecture that implements loosely coupled.
SOA and COMPONENT/EJB
Using EJBS as
SOAService implementations have many benefits and are a recommended ideal approach, but EJB is a
DistributedComponent technology, or
SOAService is somewhat different.
First, the service should be stateless, and the component component can have a state, although the EJB as
DistributedComponent is
SOAThe service is best implemented, but not all component component can serve as a service.
Second, the component component is a fine-grained, and
SOAService is a coarse-grained, component is an object designed for reuse, and service is a better way to
Elasticity ofScalability and design, attention, service is biased
Elasticity of, and if the components are
DDDAbout, implementing
DDDThought involves the use of what component route, then
SOAis already purely a completely
Elasticity ofConcept.
Do not assume that the use of EJBS has a good
Elasticity ofScalability, the distributed computing component does not represent a good
Elasticity ofScalability, because their granularity is still too fine, the granularity is too thin, causing the call to be too frequent, aggravating
DistributedNetwork load.
A business function is repeatedly called back and forth between many components, and
SOAIt is the client using one call to a service, solve this business function, the display is concise, a knife to seal the larynx, but also because of performance problems, reduce network back and forth loss, SOA provides a reduced load, the same network environment can provide more functional load processing, so
SOAIn
Elasticity ofAspects are better than those fine-grained components of EJB or CORBA.
Component is fine-grained because it uses Evans
DDDand other object methods to analyze the results of the design, the component can be regarded as a package of multiple objects, or can be an object, object methodology Evans
DDDWe recommend that we keep layering, can be more than three layers, five layers or more into, until the maximum loose coupling, the final result will inevitably lead to trivial and granular very delicate. and
SOAis a reverse process that needs to keep us up.
SOA and Evans DDD
As mentioned above, SOA is a functional block-oriented architecture, such as weather information Services, Google's query services, is coarse-grained, then is not used
SOAThere is no need
DDD, make a metaphor: DDD is to cut things very finely, and
SOAIs packing, are these two not related?
I personally think the answer is no, if there is no very delicate loose coupling separation, then how to have
SOAThe whole concept of the block? Fragments and the whole piece is a pair of contradictions of the two aspects, interdependent relative, if the loss of one side, the other side can not exist.
If not
DDDSuch
OOAnalysis design, if it is around the database analysis design, it is difficult to use the
SOAThis coarse granularity is not related to the specific technology of the high-level architecture.
If you don't have
OOSubdivision of concepts, but database-driven design concepts, you might be able to provide a database crud as a service, either JDBC or HTTP is not a service. Do not change the simple additions and deletions to such fine-grained services as
SOAServices, based on curd, should be more complex reusable components, and then used on components to
SOAThe service. SOA is a very high concept that requires a higher level of upward thinking.
It can be seen that SOA services are packaged again after the loose-coupling component is detached, and Evans
DDDis a razor that cuts off component relationships. In this respect, DDD should be a more basic platform, with high-rise buildings on the ground, and
DDDIs the synthesis of object methodology, set of analytical patterns and design patterns, when you master
DDDAfter that, the distributed component EJB is the second level you conquer, the scalability scalability become a part of your architectural habit thinking, you can really enter
SOAHigh-end "Wonderland".
Reference article:
http://www.theserverside.com/news/thread.tss?thread_id=44639
Http://www.jdon.com/jivejdon/thread/34676.html
SOA and DDD
