Introduction
The domain layer is a collection of entity objects and related business logic that is designed to represent the enterprise business model. The major scope of this layer is to create a standardized and federated set of objects, that could be potentially reused within different projects. Once identified the enterprise business model segment that is useful for the project, it is necessary to start an analysis-model-design 3 phases process.
To achieve a good domain layer designs it is preferable that the following roles get involved during analysis:
- business domain experts that bring their business knowledge
- business analysts that study the domain and provide a first modelization
- business architects that helps to prevent possible design problems that could arise during the design phase
Main design principles
I would like to put the focus on three design principles:
- Use of design standards
- Design agnostic entities
- Keep away technology’s details
Use of design standards
Design standards are what make a project looks like a unique entity to IT people that are involved in its development and maintenance. Not using design standards is like starting to write a book in English, then continuing in Italian to finish in Chinese; for most of the readers it will be unreadable. As the domain is the first layer that is designed, design standards should be defined at this stage and a figure must be delegated to be the custodian. Finally design standards applied over the enterprise boost the interoperability, reducing the need of integration efforts.
Design agnostic entities
Domain entities are not coupled to any process definition. So they are intrinsically agnostic and potentially reusable. Potentially meaning that a certain effort has still to be done to give them a chance to be really reused. When we told that the scope of domain layer is to create a federated set of domain objects modelled from the enterprise business model, is not realistic to think at a whole enterprise modeling. In most of the cases a project will need to use just a small segment of it and so modeling will focus only on that part; this is what makes more complex to achieve reusability. In this scenario is easy to focus only on those aspects of the business objects that interest the specific project, mining the chance for those objects to be reused. A speculative or a deeper analysis can help to better understand how those objects are viewed and used by other processes. Finally, before to model a new part of the business model, it is good practice to investigate if it can be already provided by other projects (well, if it is well designed for sure!).
Keep away technology’s detail
Technology is part of IT and never will be part of the business model! But still it is a common error to put technology concepts into the domain layer.
For example, a database is just a persistent representational model of domain entities, a domain entity does not exist because it is the ORM of a database table! Libraries like JPA or Hibernate should be excluded from the domain layer. If you understand that the domain layer represents the business model, you will accept that ORM is a top layer built on it for the scope of a project. Other type of technologies that are often bind to the domain are UI technologies, data persistence in general, and vendor platforms.
Domain layer classification
Inside the domain layer objects can be classified looking at their design time characteristics:
- Domain entities
- Domain services
- Domain logic
Domain entities
It is all about modelled business objects, attributes and their relationships.
Domain services
It defines services that can be implemented in the same layer or in separate layers. This gives an abstraction for certain features as logging, exception handling, that can be managed differently depending on the environment that will use the domain layer.
Domain logic
Implementation of logic linked to the business objects, as validation rules, factories and repositories.
Domain Driven Design
A small part of this topic is dedicated to the Domain Driven Design. In this post I would like just to introduce it as a great design philosophy that can be used when designing the domain layer. In my experience it helped me to completely refactor a domain layer, increasing the ROI in a very short term.
How to manage difficult cases
To make this post a bit more interesting I will speak of a scenario that is more common, and I will give my return of experience.
What discussed till now fits very well in a scenario where business documentation already exists, and the business process is clear and stable. As many of you can have experienced, this is not always the case…! Lack of documentation, missing design standards, not IT culture, people that do not want to share their knowledge are just some of the problems that can negatively impact the realization of a well done domain (and surely the others) layer. So, what to do in this situation? When we think at a domain layer, we like to imagine an heavy stone that won’t easily move from its position, so how to handle it if it looks more like a leaf under the control of the wind? And if deadlines are short? And if quality is also concerned in the short term? No panic, here are two useful tips.
Which methodology to use?
For sure a top-down approach is not feasible, can be better a mix of agile and top-down to grant quick release with a good return on quality. And for sure DDD!
How to handle missing business documentation?
IT people in a company will never replace domain experts, so do not try to write the missing domain business documents! Instead focus on all the IT documentation and try to help domain experts to find the best way to write their documents, making them understand that those documents are the most important ingredients that can decide the success of the project.
Conclusions
A well designed domain layer is essential, cause all the business logic will be coupled to it, and whatever a change risks to have a critical impact. A top down approach and an up-front analysis is the preferrable approach to design it. The most critical challange can born when in the company there are resistencies that do not permit to access easily the needed knowledge to fully accomplish the task. In this case, one way to reduce those resistences can be to make business experts as much as possible partecipate in the analysis phase together with the IT team.
