I was thinking lately that from all the books I've read related to my professional life and career, there are three that stand out. I can not decide which one had a bigger impact because each effected a different part of my life. So there is not one better than the other. I will write three blog posts about each book. They will be presented in the chronological order I read them.
-------------------
One of the most difficult to read books, and still one of the most enlightening ones, Domain Driven Design by Eric Evans is second on my list of three books that had a major impact on my professional life.
This one is a book that takes software development to a totally different level. Seemingly it leaves most technicalities behind and views the whole software from a much higher level.
Imagine your source code as a balloon filled with air. It sits between two major actors of our industry: the software developers on one side, and the business people on the others. Or if you take the people out of the picture, software production versus business domain.
In such a setting, Domain Driven Design pulls a part of the balloon toward the business people, toward the domain, while at the same time anchoring its other side in the software production department. It tries to fuse business with software by both pulling simple software concepts like modules, classes, dependencies, functionalities into business, as well as pulling business concepts to the source code.
As a software developer, I was more concerned and intrigued by the introduction of business concepts into the source code. At Syneto we work on Storage OS, an operating system for storage devices. We are both the software developers and the domain experts. So we could not pull software concepts into our domain, we already knew all the programming related concepts. But we could start working toward representing domain concepts in our code.
This had a major impact on our architecture and structure of modules. We started by implementing the Repository Design Pattern learned from Domain Driven Design. This opened up some interesting possibilities. It forced us to have each of our models represent a domain concept. As we mostly work in PHP, our modules are simple directories. Each module represents a domain concept and has a repository. The repository can provide and save objects. It's not a generic ORM though, it is more likely a domain specific query language. And what kind of objects should such a repository provide? Domain objects. These objects represent a more specific part of the domain.
For example, we can have a Network module. In this module we can have several repositories like NetworkAddresses, or HardwareLinks. A NetworkAddress repository can provide NetworkAddress objects. A NetworkAddress object represents a unique combination of IPv4 address, IPv6 address, a subnet mask, and a name. The HardwareLinks repository may provide Link objects. These represent the state of a network link: type - ethernet or fibre channel -, cable plugged or unplugged, link speed, frame sizes, etc. These are value objects, representing state. But we also have entities representing functionality like applying a NetworkAddress to a specific HardwareLink. This will result in a setting on the operating system. This setting will assign the IP address and subnet mask to a network link on a physical network card.
I will stop now and let you read and discover the mysteries of Domain Driven Design.
-------------------
Read also: 1st of 3 Books That Changed My Life: @unclebobmartin's Agile Principles, Patterns, and Practices in C#
