Business Ecology Initiative & Service-Oriented Solution

DOSOM© Concerns

Service-oriented approach to domain design and DDD look at some things differently though they share the final design goal. DOSOM© concerns are about these differences. We will discuss just a few concerns:

• Service
• Domain
• Context
• Security
• Flexibility

Before examining each of mentioned concerns, I would like to outline that SOA Governance can help in governing some concerns to the resolutions. For example, Governance may have strict policies defining the scope and boarders of DOSOM©, Reference Architecture, and low-level domain-driven design. The policies can allow an organisation having several DOSOM© even for the same domain. Assume, in a financial Fund Management organisation, we can have a set of SO domain models for Operations with Funds including so-called Fund Deal. This includes a sphere of knowledge, influence, and activities related to selling and buying Funds. Separately, we can have a another set of models for the Debit Card Payment process used in ensemble with models for Operations with Funds.

Domain Analysis and Services

For the purpose of this discussion, let me interpret 'service' as an end-to-end consumer-centric composition (aggregation) of automated and semi-automated executables operating based on the service-oriented principles and used for resolving business or technical tasks. Being in line with OASIS SOA RM, service is not an additional interface put on the top of SW components or applications, or a shell-proxy for them. A SOA service encapsulates components and applications in the form of the service's body and service's resources. SOA Business Service is a business-oriented executable that specifies the domain it works within.

For a service, the functionality model goes first while the design details and refines it. However, some authors suggest starting from a pure DDD approach in bottom-up modeling, then creating domain objects (POJOs or stateless Beans), and then exposing them as services. The real world works exactly opposite: business defines the business service and splits its implementation between business operations and technical tools. When the time comes to the development of these tools, the model of the business service reflects the business requirements (business features, functions, processes) and constraints technical solutions. The developers can use POJO/POCO, EJB, DCOM, or whatever, stateless or stateful - this depends on the business task. If we have some SW components or legacy systems already and some of them can provide required business functionality, we have to spend a fair amount of time and efforts to proof that existing SW components can work as services preserving SO principles. For example, if a procedure on a mainframe can perform very complex calculation for milliseconds, this does not mean it is suitable for the service already because it may expose its internal conditions on the consumers, serve only one consumer at a time, depend on operational support that cannot keep up with reasonable SLA, and so on.

We have to be very accurate with low-level design of the service implementation, especially when dealing with Dependency Injection (DI), Aspect Oriented Programming (AOP), and integration with resources - legacy applications and persistent storages. Here is a danger of creating unacceptable coupling between domain objects, service operations or services themselves. Different domain components may end-up with sharing data resources as well as domain objects (due to the OO principle of inheritance), which frequently represents the points of conflicts of interests in the future. Doing injections, developers do not always aware of the permitted and restricted dependencies defined in the business service model. Thus, development technique has to be under strict controls of SO framework to avoid coupling by implementation.

(to be continued)

1. Boris Lublinsky, Is There a Symbiosis Between SOA and DDD? InfoQ