Domain-driven design quickest {the basics}
Coding (Php 7.x)
From Eric Evans and Avram & Marinescu books, learn how to properly design a web application
Introduction
Let me do a little guess about you,
The reason you came across this website and are reading this sentence right now is that you like to create stuff.
If anything, I am quite sure that you create digital things and write software.
Does not matter the language you choose and, to be honest, doesn't even matter what your application does.
You see,
What is important here is that your application does something,
it helps you or your user in some way,
It may be solving a big problem or even be a simple calculator or task manager.
We all have been there.
The reality is that software is simply an instrument.
It lets us do this kind of thing, and depending on your skills it can perform the task very well or very badly.
Once you have gone a bit deeper in your developing career you surely have discovered that there is more than just writing a sequence of commands or function to achieve a goal.
Softwares need to be planned, properly designed and utilize the resources available in the best way possible.
Software design is not correct science, it requires plenty of creativity and skill in problem-solving.
It is more of an art.
And exactly like art, there are many ways to represent it.
One of the methods is Domain-driven Design, DDD for friends.
Domain-driven design is a software development concept that the language of your code must be focused on the sphere of knowledge, of the one that uses it.
Created by Eric Evans more than a decade ago, it has now become one of the standards of the industry.
In this article, you will go through Evans’s and Avram & Marinescu books and discover what DDD is and how to implement it before and during the creation of your projects.
The mini-series
The article you are reading right now is part of a series regarding DDD.
In this series, we go through the main concepts of Eric Evans’s book and Abel Avram & Floyd Marinescu’s summary to make you able to better manage your task and create software that helps your client or that makes you manager happy.
What is DDD
The concept of DDD is quite straightforward.
Web developers or software engineers are experts in the field of getting some specifications and writing code.
Problems start to appear when the programmer does not actually know that the specifications or acceptance criteria of the task mean.
If you want to create good software, you must know what the software you are writing is all about.
It is impossible to create a hotel management application if you do not have the most basic idea of how a booking system for rooms works,
What about the rota for the employees?
This knowledge is called a domain.
The end goal of the software is to enhance the quality and help us and the user working within the domain.
To improve it, what we need to do as programmers is to understand it, fix what the weak point of the project can be and improve the strong part.
Mr Evens says that to understand what the domain is, we need to talk with who is an expert in the field and with them create an abstraction of the domain.
Something like a blueprint, better yet a model.
While designing the software it is of fundamental importance to stay focused on the main purpose of the model of the domain.
It is suggested to get all the information regarding the project and discuss with as many experts as possible.
We have our deep knowledge of the programming language, its classes, methods, relationship etc.
What we need to get is detailed info about the product or service we need to develop.
We can collect this information in several ways:
- Graphically, using schemas and diagrams
- Textually, via a textual description of the requirements needed in the project.
One of the reasons it is very important to do code design before actually starting to code our application is that a mistake made during the planning is way easier and faster to fix than an error made while the application has been already developed.
This is not only a question of time, that, of course, is very important, but is also a matter of cost, for you as a developer and for the company or business, you are working with.
There are many ways to do software design.
One of the oldest but still used today is the Waterfall method, using a series of stages the project moves to the next step only after the current one is complete.
This way to work on a project has been one of the most popular for decades and, in my opinion, it's a very good system because if you are not a procrastinator it actually makes things done.
The problem with the Waterfall approach is that there are several defects.
First, one is the limit of feedback provided by the owner of the project.
If fact, he/she is only able to see the product only when the step has been completed, not allowing for time to move to another part of the project.
The second way software can be designed is by using the Agile methodology,
The main problem that this system solves is the way it manages time.
Using Agile you do not need to know every trait of the system you are building beforehand.
You can start to code, the bit you are able to do with the information you have available, then move to another part of the code when they get more info.
This method, including a subcategory of this called Extreme Programming, is one of the most used of the last decade.
It’s the best benefit is the complete elimination of waiting time, also called Analysis Paralysis.
As per the Waterfall, in Agile too there are downsides.
Agile is not the simplest method to work on, also all this flexibility in editing the code can lead to spaghetti codes and less reliability if the standard in which these codes are written is not high and consistent enough
The Ubiquitous Language
Ubiquitous [adjective}
Seeming to be everywhere, found or existing everywhere.
dictionary.cambridge.org
We said in the previous section of this article that to make a software that will end up to be useful we need to have a clear model,
We have also seen that the best way to create a model is to have more than a person, each with a different skillset working on the designing and planning of this model.
A domain expert is the one that knows the ins and out of what is happening in the industry and why we need the software.
His knowledge is very different from the one of a web developer.
He is an expert in classes, methods, using PHP functions and variables.
But usually, he knows nothing about the environment the software needs to live in.
Imagine having a meeting with your product manager (or client if you are a freelancer) and need to talk about the requirements of the project.
Chances are the two of you will use a completely different language when describing problems or coming up with solutions.
So,
What language needs to be used?
It will be the developer language or the domain expert?
One of the main principles of domain-driven design is to use a language that is based on the model,
The model is what all the parts need to refer to, it is the spot where the software integrates with the domain.
The reason we do meetings and use speech, written documents and diagrams is to make sure the model is created properly and fully understood by all the parts that play a role in the project.
The easy way to spot an error in the design of the model is when one of the parties involved does not understand something.
This is a clear sign that the language is not ubiquitous but it is included more toward one of the sides.
A method often described as the solution for creating models that are easily understood by many sides is the use of UML.
Overall UML diagrams are a good solution for building models because they can describe the key functionality of every object inside our software plus they can implement the relationship between these objects.
The few problems of using UML is that they rarely can cleanly express constraint (often you need to use side notes for that), plus even though they are very helpful at the beginning once the project becomes of large scale, the model can quickly escalate in a cluttered mess.
Another approach for creating a model that implements ubiquitous language is to write down a document.
This document can include small or big diagrams, anyway be careful because adding a lot of diagrams to a document is asking for trouble.
The big downside of this is that using documents is time-consuming and also there is the risk that the document can become obsolete before completing it.
Eventually, the last technique is to use code.
If the code is well written, scalable and uses the SOLID principle it actually can be more descriptive than the other method.
Nothing more to say on this, if you want to improve your code this blog is full of resources that can help you with that.
Model-Driven Design
Let’s get to the code
So, we have seen how important it is to have a model that deeply reflects the concept of the domain, it must be easy to understand and very accurate.
We have also seen that to develop a useful application we need to use ubiquitous language, it has to facilitate the communication between the domain experts and the web developers.
It is required to discover the key concept of the application that should be used in the model.
The third step is to implement this model into the code.
What you, as a web developer, need to understand is that having a great model doesn’t mean that the result will be a great application.
The quality of the code is what makes the application great.
If you need you can improve your code by learning about the basics of PHP.
A domain can be displayed in dozens of different models and each model can be translated into dozens of different ways in the code.
Also, keep in mind that each problem that our application needs to solve can have more than one solution.
The question here is what is the best way to put all the work you have done so far creating the model into the code?
The Analysis Model
One of the most popular techniques in the use of the analysis model.
It is the result of the analysis from a business domain standpoint.
As you may have understood it is more focused on the business rather than the code to use.
In fact,
this method does not consider the software used or its implementation.
This is a big downside because this type of models isn’t built with design principles in mind.
The developers that will work on these models need to adapt the code or create different designs when needed.
Analysts and developer must work together,
If analysts work alone they can create a very detailed model, with diagrams, schemes and writing but there will be a high chance that these won't be grasped completely by the developers.
Also, analysts commonly do not know anything about classes, objects, their relationship and their behaviour.
Using this type of model, without offsetting these cons can lead to the model being abandoned soon after the code starts.
Relate Domain Modeling
The model should be created with a joint effort from analysis and developers.
The fundamental idea is that including web developers into the modelling process the model can already describe relationship and software principles from the start.
Which will be easier to translate to code once the modelling phase has ended.
The people that are in charge of writing the code must collaborate and understand completely what the model is all about.
They are responsible for its consistency and integrity once the model has been translated.
Web developers should understand that every change in the code means a change in the model and refactoring it means to get further from the original plan.
Some domains like mathematics can be modelled and implemented using procedural code.
The reason is that many theories are simply functions and data structures.
But procedural languages are of very little assistance when it comes to model-driven design.
These languages do not have the main constructs necessary to implement the main component of the model.
On the other hand, Object-Oriented programming is the best way to implement models to the code.
In fact, both the model and the style of coding use the same paradigm.
They have objects and many relationships between them.
OOP helps to reflect the objects within the model into their programming counterparts
Conclusion
Creating an application is not just a matter of putting your headphones with electronic music on, make a cup of coffee and go for it.
Especially at a higher level in your career, you will discover that you must understand what you have to build before actually starting building it.
Imagine how bad it would be to deliver a week-long project to your client to only then discover that he does not actually need any of the features you implemented.
Even worse, having a task from your project manager and deploying something wrong.
It is going to cost a lot, both in terms of time and money.
In this first article, you have seen the basic concept of Domain-Driven design, what models are, the ubiquitous language and how these should be implemented in your code.
In the next article, we’ll see what actually are the building blocks of DDD in the code.
If you are interested in learning that, subscribe to the newsletter below and I will be sure to notify you when the next article will be out.
What can you do in the meantime?
You have read enough theory for today it is time to get on some code, have a look at the basics of OOP or, if you feel brave, you can implement the OOP concepts with the builder design pattern.
