Introducing MEF.DEV

MEF. DEV is application development, hosting, and management platform that can help operators accelerate the transformation of legacy BSS features. The platform supports the domain-driven design and business analysis with the ability to generate code based on Domain Driven Design models and a unified development process. It provides a collaborative approach to software development that helps companies get a software solution for business several times faster than if it were done by a team of internal or hired developers.

Acceleration is achieved by forming a joint project team of various teams with a narrow specialization for developing a specific product in several parallel streams at once, each of which will write its piece of code, then the results of their programming will be combined into a single whole. Thus, the end customer, firstly, saves time and gets the product faster, and secondly, receives twice as many helpful resource for development. Developers learn to work in maximum synchronization with other teams with documentation updated in real mode, thereby minimizing alterations and getting the opportunity to work with each specific team at any time convenient for it from anywhere in the world.

Essential advantages of the MEF.DEV platform:

in the MEF system. DEV one product or project is written simultaneously by different development teams
use loosely coupled code that is automatically assembled into a single unit
source code in MEF.DEV can be generated and hosted not only in cloud, but in-house, i.e. inside the enterprise
transparency of data models and auto-generation of the technical specification of each version of such loosely coupled code
automatic code generation of updated data models that support such patterns as model-first and database-first, including using a reverse engineering approach

Open API	Container Composition	Smooth DevOps
The REST API, as the important element of the MEF.DEV platform, expands the packages functionality available on it, by exposing its resources (for example, accounts, subscribers, and services from BSS package), using unique URI values for external interaction (system-to-package) or the names of entities within the same domain for internal (package-to-package) interaction	MEF.DEV entities provides to you much more than Dependency Injection or Inversion of Control - it gives developers easier configuration and consistent management in larger projects without worrying about where or how a particular application/package is configured, and no matter how they use the embedded package - getting exactly the implementation they want	To improve development workflow the MEF.DEV provides to you flexible continuous integration tool for the SDLC process based on guided versioning, configuration management and auto-rollback features. Both general connectors for backend and frontend can be used in the self-development - providing you "out of the box" automatically generated documentation for the domain-driven-designed entities

Unified Development process

MEF.DEV platform provides accelerated and Agile application development capabilities for enterprise enterprises. The platform aims to increase business agility, especially in legacy environments, by standardizing Legacy -> Digital transformation processes. The platform has a graphical user interface that simplifies integrating and deploying applications.

The usual Developer's 'To-Do' Checklist are presented below:

Create or auto-generate a new package
Deploy the initial version
Do dry run
Create a version-dependent configuration
Create new versions of solution components in Agile mode and deploy to stage environment for E2E and smoke testing
Review the auto-generated specification before publishing
Publish the application package to production environment according to the rules of the Change Management Process

Entities as OpenAPI core

The MEF.DEV platform automatically expose the unique URI values for specific version of the data models (Entities). These Entities provide access to business logic and specific (native) data storage through composition, much more than Dependency injection or Inversion of Control. Composition gives Enterprise developers a more straightforward setup and sequential management in larger projects without worrying about when, where, and how a particular application/block/module is configured. Regardless of how they use the embedded application/block/module, they get precisely the implementation wanted.

Domain Driven Reference architecture

The concept of a Reference Architecture itself is defined by the ISO 15704 “Enterprise Modeling and Architecture” standard, which specifies that model-based enterprise architecture should support the idea of reusable reference models. It is also indicated that reference models require adaptation to a specific enterprise, and if necessary, some specific models that describe a separate entity of a specific enterprise or its part can be applied. In other words, the enterprise architecture should:

allow modelling the project life cycle from initial concept to functional design or specification, detailed design, implementation, exploiting, operation, and ending with decommissioning;
encompass the people, processes and infrastructure involved in fulfillment, management, and enterprise business control. Thus, from an application point of view and in the context of this article, architectures can be divided into system architectures and enterprise architectures.

From a practical point of view, the Reference Architecture is based on a set of decision patterns and approaches, which makes it reusable for launching new services and services on an Enterprise-wide scale – in other words, “out-of-the-box”

Digital transformation begins with the definition and standardization of domain services or products with a domain-driven design.
From these services or products definitions, Entities and Action models are developed. They include common types and constructs for further exposition and behavior that span all services and products.
The business requirements and use cases are specific to each domain. They define functional requirements, use cases, business process flows, etc., related to specific Entities or Action.
The platform maps the applicable Entities and Action models to relevant data schemas which are then exported & packaged into App Logic Functions along with related autogenerated documentation and developer guides.

Shared information model

To support NGOSS concept and the TM Forum recommendation, the MEF.DEV packages are implemented based on TMF shared information models, are focused on the business processes of service operators, organising the sharing of information about consumers, services, available resources, suppliers, partners and other information in the framework.

Visualizing the contents of a specific IoC container (actually a developer-specific implementation) gives transparency to all other platform participants.

Example of SID-model for the Telecom BSS domain is available as BSS.Entities