Big Blue Series — 17 — Factories: A Pattern for Software Consistency
I once was asked to help design automation of an essential oil distillation factory. The reason the company owner wanted this automation was to reduce the variable nature of the output of the product being distilled. He wanted each lavender oil batch to be almost undetectable in its differences to other lavender oil batches. In the natural world, this idea is good, but a system will not be perfect as the results are still influenced by other factors that cannot be systematized like the effects of weather and more. We used some Domain-Driven Design (DDD) concepts to model this out, and in the end, it worked like a charm the very first batch. It is now a patented process.
Software fortunately is less vulnerable to natural elements in most cases. We benefit because we can control or plan for variability in far more precise ways when we create new things with software and beyond. One way we can leverage control when automating complex software elements that get generated in code, is to stamp them out using a Factory. It should really only be used to generate complex things. If you need an element that has no real complexity, let the Entity or whatever that element is, generate the thing itself.
In Blue (Evans, 2004) there are many wise nuances to designing these Factories. We will address a framework for thinking about these Factories and then I highly recommend the middle of Chapter 6 as a deeper learning opportunity. The finer points can feel a little Jedi like, but it should not scare anyone off from giving Factories a chance to improve the Domain Model when it seems like a good idea to implement them.
Every Customer Aggregate of Entities, Value Objects, Services and Events is going to have different information and be unique in its identity. The rules for generating those Customer Aggregates can become complex. Also, these instructions are not going to be very different from customer to customer for the most part. So, it pays dividends in code readability and more to contain those Customer Aggregate “creation” instructions outside of the Customer Entity Aggregate Root where they would normally live.
By taking complex creation instructions and housing them in their own space, we get that complexity out of the way of the Aggregate or other element itself. It reduces the number of lines of code in all the places, and it even makes good use of the Single Responsibility principle. If a Factory gets unmanageable in its design, then the code is contained enough to remodel it again and refactor toward a more suitable design.
Designing a Factory
In systems education, it is a basic concept to learn about ITO. Input — Transformation — Output.
You send some raw materials in to a component, that component assembles a new thing using the raw materials and the preplanned instruction set directing exactly how the product of that system should be crafted. Once created, that product is shoved out the door, ready to be consumed somewhere else.
We can capitalize on both the idea of a system and the ability to manage the variability of information using these Factories.
When you craft these Factories as Domain Members, be sure to have their inputs and outputs such that they can absorb new functionality over time. If you want a Factory to make a Customer Aggregate, don’t throw several commands and expect the Factory to know when you are done with these haphazard commands. A Factory should get all of the parts it needs to build a thing one time and completely. No weird science here. When it completes the creation of that thing, it is done with it. It does not need to ever see it again. Other code should be updating entities. Nothing should update Value Objects since they don’t change ever, they should be fully crafted correctly at inception.
Lastly, your inputs should be clean. If I need a spare part off a car, don’t give me the car and ask me to disassemble the car to get the part. Just give me the part.
Locus of Control
Perfect! Where do we put these Factories Mr. DDD? Well, that depends, as the saying goes in software.
To get there, I want to introduce a concept new to this Big Blue Series called the Locus of Control. This concept is taken out of the Mental Health and Wellness field, but I personally believe it has some interesting ideas that are applicable to DDD.
Locus of control refers to the extent to which people feel that they have control over the events that influence their lives. ~ (Cherry, 2014)
I seldomly understood software to be a relationship-oriented process. I was wrong. In fact, I was a relational database designer! But when it came to code, I barely scratched the surface of this idea. And don’t get me wrong, I don’t believe that a relational database entity design is the best map for a Domain Model. It is often the wrong place to get ideas for the Domain Model.
I really did not catch on to this idea of code being relational in a Domain sense until about the third time I read Blue and even now, I am still learning all about the relational properties of objects in code.
When forming Aggregates, placing Factories, or doing much of anything else in the design process, now, I empathize with the thing that I am asking to work for me, namely these Model Elements. It sounds like I might not have all my faculties on this point but bear with me.
If you have ever been a manager with low authority yet high pressure, you may have tasked some of your team to accomplish things but since you had low authority, you might not have been empowered to supply that team with all resources needed to get the job done.
When I was asked to automate the essential oil factory, we had no electrical engineers, no mechanical engineers, and no automation engineers. Knowing I had no one on the team that could make this work, I initially declined the opportunity with one caveat. If the company supplies at least those key resources, I would love to work on that project. They supplied and we succeeded.
Location Location Location
When you think of your Model, what it needs to do, when it needs to do it, and which element has the best vantage point for performing certain tasks, it is not much different than managing people. Does it have all the resources it needs to do what I have asked it to do? Do we need to offload this effort to a new resource to make the workflow better. It really is similar, and I am sure the analogy falls on its face at some point. None-the-less, consider the Locus of Control when trying to place any element in the Domain Model, including Factories.
Factories can be a task right inside the Aggregate or Entity that it is going to create.
Factories can be on the outside of those things because the world outside the doors of those Aggregates etc. can better handle the Factory needs.
Conclusion
Factories are just larger creation methods and make deliberate work out of the complexities of the Domain when generating elements of the Domain. Use with caution. Go forth and create.
Now, what to do about storing these Aggregates and other items? That is where Repositories come in!
Hope you have enjoyed this series so far. Please follow the Domain Intelligence Today publication and signup at the bottom of this story to get an email notification when new articles appear!
Until then,
I hope I see you in the next installment of — the Big Blue Series.
References
Cherry, K. (2014, January 3). Locus of control and your life. Verywell Mind. https://www.verywellmind.com/what-is-locus-of-control-2795434
Evans, E. (2004). Domain-Driven Design: Tackling Complexity in the heart of software. Addison-Wesley Professional
