One of the most important (first) steps in architecture modeling encompasses the description of the domain model. This model introduces all entities relevant within the current domain as well as their relationships and interactions. It represents the main language all stakeholders should understand. All further activities in architecture modeling basically take the domain model and enrich it with additional infrastructure entities.
Sounds very abstract, right? Let me give you a concrete example. Suppose, we are going to develop a Web store. What are the typical objects that appear in the problem space and are well known to all stakeholders?
For example, I'd expect entities such as:
- web store user: someone accessing the web store
- customer: someone interested to buy items
- shopping cart: used to add, remove, pay goods
- product catalog: presents all available products classified by categories and allows to search for these products using different types of query
- customer database: place where all customer information is stored
- order processing: responsible to process orders
If you think about this example further, you'll recognize there are some typical relationships between domain objects. For example: a web store user could be a customer or an administrator. A customer typically owns at most one shopping cart at the same time.
You also can easily defer some interactions between the entities. It is obvious there must be a relationship between the shopping cart and the product catalog, because the information about purchased items is read and updated from the product catalog. Of course, the shopping cart needs to interact with the order processing system after the customer has pressed the order button.
With other words: when thinking about how use cases would be mapped to sequence or interaction diagrams, the knowledge about the domain model is essential. It is the step taking you from a black box perspective to a gray box perspective.
There are different ways to express such a domain model. You could invent a graphical representation or use a textual language instead. If a domain object model gets formalized, we call this a DSL (Domain-Specific Language). In this case, engineers could even provide generators that map from the problem domain to the solution domain, i.e., that map problem domain objects and relations to solution domain objects and relations.
Using domain models offers huge advantages:
- it introduces a common vocabulary among all stakeholders which supports effective discussions and often prevents a steep learning curve for domain dummies
- it reduces the chance of missing to address important parts of a domain
- it eases architecture modeling significantly
- it helps focusing on the problem domain instead of always diving into the solution domain
- when enriched with domain patterns (analysis), it boosts productivity
It is neither necessary nor useful trying to come up with a complete domain model in the first place. In most cases, there will be an initial, maybe incomplete, domain model which engineers together with the other roles will evolve over time.
There are several examples, where the domain model is already available. Think about GUIs, compilers, and some kinds of healthcare domains. In these domains, it is useless and a complete waste of time to come up with your own domain model.
So, whenever you are being involved in a new software architecture, always mind the domain object model! It will be your best friend.
6 comments:
Hello Michael.
Nice tip. Still, the term is sometimes confusing since modeling is actually taken as describing the solution using the domain language.
Thus, Domain Model sounds like any model, when in fact you are referring to the a basic, general model (inside the scope of a domain) that shows the most common concepts (objects) and relations between them, rules and semantics. I call that the Reference Model.
You can "model" the solution using the concepts and rules from the reference model, and that reference may be even constructed by business specialists and not necessarily by the architect.
Creating a model that "introduces all entities relevant within the current domain as well as their relationships and interactions" may be a daunting task for certain domains. So, the reference model is sometimes just a subset of the domain, enough to solve the problem at hand.
And, as you go solving the problem and refactoring during the construction, you may revisit this reference model to adjust it, adding more concepts of relations that you may find are needed.
William Martinez Pomares.
Architect's Thoughts
Any model is only an abstraction of real world entities following a specific goal. With modeling you could describe any domain, the solution as well as the problem domain, or even both. Thus, a domain object model should only introduce a relevant subset of the problem domain. It is essential to start with such a domain object model and then iteratively add objects from the solution domain as I described in my onion model.
It is probably a common case that the domain model (usually named) does not get enough attention. Maybe it seems to obvious (while brainstorming) to document or produce such a model. But it seem good to start analysing the black box using a model with the elements of the domain. What I want to highlight (or actually bring forward) is the question of terminology. Too me it seems like a very good idea to once and for all establsih the correct names of things in the domain. I believe that the domain model could act as a theasarus for the project. The correct names for this and that are inserted in the model and should be used by everyone to avoid confusion. Or is that less relevant at this stage?
Best Regards, Bjorn
Dear Bjorn,
you are absolutely right. Such a terminology is really important. It definitely serves as an important first step to clarify the terminology.
Each model only serves one purpose, communication between different stakeholders. Thus, the model must serve as an agreed style of communication. A model is only expressive when the entity names are understood. I have been involved in projects where even domain experts disagreed on some domain-specific terms. If this different interpretation is not resolved explicitly, then the project will suffer from all kinds of misconceptions and misunderstandings.
At the end, we need to enrich the model with relations between the domain objects. The domain object model capures all those entities from the problem domain, we need as a base for the solution domain. It is not intended as a complete description of the whole domain which would be impossible in mmost cases
- Michael
Hello again.
Michael: totally agree, you are saying in two words what I said in four paragraphs.
Bjorn, Michael:
Maybe that is what I may point to when using the word "reference", that basic set of terminology, agreed upon rules, relations, and semantics. That Domain Model (which I still think is a confusing term and you can validate that even in Wikipedia) is not simply basic but also critical to communication. And that communication between stakeholders and the development team is crucial, to avoid common semantic dissonances.
So, note that I not only include the terminology (like a glossary), but also rules, relations and semantics.
William Martinez Pomares.
Architect's Thoughts
I totally agree :-)
Regarding the issue of domain models: guess, this is very common to our IT world. I am a bit sceptical about "reference model" because this is commonly used in the sense of a standardized, commonly agreed model which is often not feasible for most domains but very general or simple ones.
No matter how we call it. We need a model expressing the problem domain for designing the architectural baseline.
- Michael
Post a Comment