This is not a pattern itself but rather a philosophical stand point.

How many times have we seen ourselves running the same issue over and over again regarding a business use case and we can not glimpse the line at the end of the tunnel. How many times have we dug endlessly into the code searching for understanding the business rules in order to make, for example, a simple change in the business logic. It turns into a nightmare to undertake such a changes because the lack of guidelines and perspective that provide an approach other that just simply piling lines of code out of a couple of business requisites without a profound domain analysis.

And this my friend, is the day-by-day in a consultant’s life.

Domain Model Layer

The Domain Model is the differential factor of our application. It’s what values the system we intent to build. In this layer live all the policies, constraints, rules and contracts to our business logic.

In a very rough example, the Domain Layer is what differences Google from Facebook, as simple as stated.

The bigger a Domain Model is, the more complex its Design turns into. This is where Design by Contract comes into play. Of course there are lots of concepts we should step into when talking about greater domain modelling, especially if we’re gonna deal with desired scalable, testable and maintainable systems, even though we’re gonna focus on the Domain layer since i think it’s the Core of high level solutions from a designer stand point.

Nonetheless there is a concept we should never ignore on this and it’s Language Oriented Design.

Language Oriented Design.

A little while ago i found an interesting article coining(not sure) the term i had never heard about and is no other than Language Oriented Design.

https://parametri.city/blog/2018-12-23-language-oriented-software-engineering/index.html

This is such a great insight because it takes the attention to that point where the Architect needs to separate the business domain from the infrastructure domain. This is sometimes hard to achieve since we developers tend to think that the tools we’re using, e.g the framework we build the solutions upon, are our very own application, and we get lost in the myriad of policies and rules of the framework, making our application impossible to scale not to talk about the fact that we doom ourselves to the whims of the framework and its creators.

We tie our solution to the Framework so hard that if for some reason, the Framework passes away some day in the future(perhaps this may never happen) or we find a better platform we’d have to throw away the entire solution and build it again from the ground up.

The point of L.O.D is that everything is an API or language: the Framework, the language the framework is built on top, our solution is also an API, all the libraries our system relies on is governed by an API, external systems we communicate with we do it by interacting with their APIs via standard protocols and so on.

So the mission of an architect is to detect and split up all the components and actors in our Domain organizing the dependencies so we can define our own APIs and the relationships with the rest of APIs lingering around. This is what actually, in my onw humble estimation, L.O.D stands up for.

By doing so, we end up creating service-isolated-driven components not attached to any framework since the communication happens through well contracted APIs so we can easily replace any component with the lesser of efforts.

And this is my friend where Design by Contract approach shines the most.

Design by Contract Approach(D.b.C)

Coming back to square one where a Language Oriented Design is a must, we have the path clear for us to start making thinks easier to further changes, testing and so on. given the fact that everything is an API, our whole system is wrapped around the idea that all interactions, that mostly is what complex systems are about, are subjected to data and service contracts for the sake of communications.

The most thrilling thing about dealing with APIs is that we can define interfaces that technically are the legislative powers of the machinery of our system. We legislate by defining the contracts for the components of our systems to communicate with each other, the policies of our solutions are those contracts embodied by such an interfaces, and the workers that execute those policies are the specific implementations of those interfaces.

The business rules/policies/constraints/behavior of our Domain live in the Domain layer, this is what provides value to our Application and makes it different from anything in the Universe.

By using the Unified Model Language(UML) and a standard domain-policies-transporter oriented language(e.g XML) to design the Architecture of our Domain Model we can build D.B.C compliant solutions for the sake of scalability, testability and maintainability.

There is a long long way to grow this up but i think it’s worth trying it out so eventually it will paid off all the efforts, time and endeavor we soever might apply on.

Have you noticed a concept involved here? I’m you have, it’s no other than Domain Driven Design which is, of course, way longer and richer than what D.b.C is. But D.D.D is a whole universe itself that deserves a entire book(in the lesser of cases).

Conclusion

This has just been a glance at a concept i think is worth trying digging into a little deep since ti takes into account separating the things that make your business valuable in an application allowing you that way scale and maintain your system with the lesser efforts.