Another important aspect of DDD is the domain logic discovery and analysis that leads to domain decomposition and re-composition for technical implementation. I am afraid that if you ask DDD professionals about where they get the knowledge of the domain service, entities and domain logic, the majority would refer to the business operational teams, their manages and leads as well as to the business analysts. Sometimes, the IT tries to discover or reconstruct domain logic from the visible business actions and creates 'domain entities' and 'domain services' based on those discoveries. This may and in many cases does lead to the dangerous mistakes in the domain understanding; this is where the service-oriented approach and DOSOM© can help the most.
The service-oriented business model decomposition starts from the top, from the enterprise/LOB business model, quite above the daily operation activities of business operational teams. With proper decomposition, it can become simply evident that several business operational teams perform activities that are not in-line with current business goals and objectives of the company. Why is this happening, it's another question and story. Nevertheless, the discovered "business process" and 'domain services' may reflect business capabilities of the past or even appear as the operations carried out just for the team convenience. If IT understands such vulnerabilities, it can extend its areas of business analysis and eventually find the solution that not only address the real business needs/processes but also simplify the business operations, i.e. some outdated business operations may be retired. The DDD combined with SO vision is a very perspective approach to making IT a partner, not a servant of the Business.
At the QCon-2009 in London, Eric Evans announced a few more DDD constructs that he had found very useful in DDD for the last 5 years passed since his fundamental book was published [1]. These constructs are Domain Events and Domain Aggregates. If the former is self-explanatory, the latter is about compositions of the 'domain entities' in the consistently set boundaries; the compositions that act as conceptually single units. Let us look at these constructs from SO-DDD perspective.
Eric Evans explained that he sees the Domain Events much wider than possible events in the boundaries of a predefined "business process"; those events are known up-front. His and my interpretation of the Domain Events is that we are talking about business events happening in the business domain, expectedly or not but that were unknown at the moment of the modeling. That is, a Domain Event is a prepared container for handling real life business events. Such Domain Events may become triggers for creation of Domain Aggregates in accordance to the business rules.
The Domain Aggregates, in turn, appears as a construct that has its own business task, input data and functions/commands/operations, outcomes - results or Real World Effect, and concrete content comprised participating 'domain entities' and 'domain services'. Can a Domain Aggregate encapsulate an implementation of a "business process"? We do not know and do not care whilst the Domain Aggregate provides for the task resolution and a Domain Aggregate consumer does not need to know and to interact with individual participants of the Domain Aggregate.
The Domain Aggregate construct allows for comprehensive mapping between SOA business services and domain-driven model. In other words, I see a Domain Aggregate as a domain SOA service because
1. Domain Aggregate provides for concrete business function and participating 'domain entities' and 'domain services' are invisible or unrecognisable to the consumers
2. Business operates with functions, not with objects, and Domain Aggregate is much more realistic business model than an individual 'domain entities' and 'domain services', which, sometimes, also can successfully model business reality but it is a rare case
3. Domain Aggregate may contain just one 'domain entities' or 'domain services' and this conclusion unifies aforementioned comprehensive mapping
Extending this aggregation concept further into the SO sphere, we are getting a domain SOA aggregate service comprised a set of domain SOA services, that is, we can have an aggregation of SOA services based on the sets of Domain Aggregates.
When we touch the Domain Event from SOA perspective, we re-open a 'bearded' discussion whether events and EDA is a part of SOA, may be a part of SOA, or exists totally independently. To my knowledge the consensus in this discussion was not reached. If we take SOA as 'dead SOA in IT' that was about the use of Web Services for system integration, probably, we can conclude that SOA situates separately from EDA. Since I 'worship' SOA as a concept of architecture and even enterprise organisation, I certainly consider EDA as one of very powerful realisations of the service orientation model.
I think that EDA perfectly fits into the SO architecture, i.e. Domain Events are not strangers for SOA. The Domain Service-Oriented Modelling has to consider business events as the originators of the invocation of service compositions (aggregates) as well as the triggers for creation of new service compositions or even individual services (Domain Aggregates), on-the fly or off-line.
(to be continued)
References:
1. Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley, 2003
Leave a comment