Why do we call engineers who are building Architects? When I visited Rome in May 2018 and visited the colosseum, our guide pointed out that the colosseum arches were the inspiration for the architecture science or the knowledge of how to build arches. How to build arches is a very complex process, it took a lot of effort to rediscover it in the Renaissance times. We call software engineers who design large software architects and those who guide organizations through the business, information, process, and technology changes necessary to execute the organization strategies Enterprise Architects.

Figure 2: Me inside the colosseum

Enterprise Architects define solutions to business problems by creating a solution architecture blueprint. Solution Architecture is the process of defining the design or organization of different systems and components to fulfill a business needs and requirements. By systems and components, I mean software applications, hardware devices the software runs on. With the emergence of Microservices enterprise architects are working on defining the required microservices for building IT assets that enable the organization in achieving it business goals. Domain Driven Design – Bounded Context principle resonates with how to define the actual size of Microservices (“Micro” does not mean tiny in this context). Recently I was chatting with a couple of colleagues about how to define and implement strategies for embracing Microservices and Domain Driven Design (DDD) within a large organization. And the following question came up:

Can we apply Domain Driven Design to existing Mainframe code and legacy Monolithic Applications?

My answer was “Yes we can” just like Obama slogan . DDD is about defining and designing better software that achieves the business goals, has supple design that can be enhanced by adding new features in the future, and can be easily understood by software developers and the business experts. You do not need to adopt new platforms, technologies to do that. You can app the DDD principles to any large complex business solution you are building. Think of DDD as a guiding way to approach a problem by decomposing it into smaller problems and tasks. You can apply that to anything in the universe just listen to Stephen Duneier Ted Talk https://www.youtube.com/watch?v=TQMbvJNRpLE

What is Domain Driven Design?

Domain Driven Design is an approach to combining business analysis with software design to make sure the developed business software meets the business problem it is trying to solve. It is part of the agile software methodologies that focuses on the actual software being built. But unlike extreme programming or the other agile methodologies where the absolute focus is on the code written, Domain driven design focuses on:

1. Creating a representative model of the software- the focus of this model is on the actual components, classes, packages, modules and relationships that actually solves the business problem at hand rather than the code required to code the software for the chose platform, framework etc.
2. Making sure that the model is understood by both the Business experts also referred to as Domain Experts and the developers
3. Making sure the model and the code are in synch

Domain Driven Design introduces several techniques to help with achieving those goals:

1. Divide the problem domain into several smaller domains called Bounded Context
2. Bounded Context
3. Ubiquities Language
4. Refactoring both the code and the model

To be continued …