diff --git a/README.md b/README.md index 300f4271b..2e698b5aa 100644 --- a/README.md +++ b/README.md @@ -39,11 +39,19 @@ Defines a standard format for storing and sharing business logic. A clear set of > _Morphir’s automated processing helps disseminate information which otherwise may not be understood or shared at all, a useful tool when brining elements of business logic to conversation outside of its immediate audience (i.e developers)._ ---- +## FINOS Morphir Resources [Morphir Resource Centre](https://resources.finos.org/morphir/) ---- +| Episode | Description | +| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | +| | Introduction to the Morphir Showcase | +| | What Morphir is with Stephen Goldbaum | +| | How Morphir works with Attila Mihaly | +| | Why Morphir is Important – with Colin, James & Stephen | +| | The Benefits & Use Case of Morphir with Jane, Chris & Stephen | +| | How to get involved – Closing Panel Q&A | +| | Morphir Showcase – Full Show | # An ecosystem of innovative features diff --git a/docs/application_modeling.md b/docs/application_modeling.md index 8aae84e5e..907406af4 100644 --- a/docs/application_modeling.md +++ b/docs/application_modeling.md @@ -1,52 +1,62 @@ +--- +sidebar_position: 4 +id: modeling-applications +title: Modeling Entire Applications +--- + # Modeling Entire Applications Morphir Application Modeling imagines an evolution of programming as: -* You code, just pure business logic. -* That code is guaranteed to be free of exceptions. -* Merging your code triggers full SDLC automation through to deployment. -* Your application automatically conforms to your firm's standards now and in the future. -* Your users have transparency into how your application behaves and why. -* You retain full control to modify any of the above. + +- You code, just pure business logic. +- That code is guaranteed to be free of exceptions. +- Merging your code triggers full SDLC automation through to deployment. +- Your application automatically conforms to your firm's standards now and in the future. +- Your users have transparency into how your application behaves and why. +- You retain full control to modify any of the above. Most applications generally follow a small set of well known patterns based on how the application will run -(as opposed to its business purpose). These patterns are what many application frameworks are built around. As a -result, much of the development process is simply following recipes to build code to these patterns. +(as opposed to its business purpose). These patterns are what many application frameworks are built around. As a +result, much of the development process is simply following recipes to build code to these patterns. -There is another set of patterns that sits in the fuzzy area where the business patterns meet the technical ones. These -patterns are not entirely business and are consistent across applications regardless of how they will end up being -executed. It's likely that these patterns will remain unchanged even as technology evolves. If we can capture these -patterns in our models, it would allow us to move execution across different technologies without changing our models -at all. This is important because an individual application usually exists within a larger ecosystem. Constantly -keeping large numbers of existing applications up-to-date with the latest ecosystem changes, commonly referred to as -*hygiene*, takes a lot of development effort that subtracts from a team's ability to provide business value. +There is another set of patterns that sits in the fuzzy area where the business patterns meet the technical ones. These +patterns are not entirely business and are consistent across applications regardless of how they will end up being +executed. It's likely that these patterns will remain unchanged even as technology evolves. If we can capture these +patterns in our models, it would allow us to move execution across different technologies without changing our models +at all. This is important because an individual application usually exists within a larger ecosystem. Constantly +keeping large numbers of existing applications up-to-date with the latest ecosystem changes, commonly referred to as +_hygiene_, takes a lot of development effort that subtracts from a team's ability to provide business value. -So what are these patterns? Here are some core patterns that drive a vast subset of applications: +So what are these patterns? Here are some core patterns that drive a vast subset of applications: -* **API** - The combination of inputs and outputs that external applications use to interact with the application. -* **Local State** - The information owned and managed by the application. -* **Remote State** - Any information that is required by this application but not managed by it. +- **API** - The combination of inputs and outputs that external applications use to interact with the application. +- **Local State** - The information owned and managed by the application. +- **Remote State** - Any information that is required by this application but not managed by it. These are the core building blocks of many applications and can be implemented in a variety of technologies. -Let's look at an example. We'll use Morphir's Elm modeling support, so +Let's look at an example. We'll use Morphir's Elm modeling support, so [follow the installation instructions](https://github.com/Morgan-Stanley/morphir-elm#installation-1) to get started. ## Application Overview -For this example, we'll look at a set of interacting applications that form a complete order processing system. They include: -* [Books and Records](https://github.com/Morgan-Stanley/morphir-examples/tree/master/src/Morphir/Sample/Apps/BooksAndRecords) - Keeps +For this example, we'll look at a set of interacting applications that form a complete order processing system. They include: + +- [Books and Records](https://github.com/Morgan-Stanley/morphir-examples/tree/master/src/Morphir/Sample/Apps/BooksAndRecords) - Keeps the books on what orders have been executed. -* [Order](https://github.com/Morgan-Stanley/morphir-examples/tree/master/src/Morphir/Sample/Apps/Order) - Processes +- [Order](https://github.com/Morgan-Stanley/morphir-examples/tree/master/src/Morphir/Sample/Apps/Order) - Processes order requests and records any confirmations to Books and Records. -* [Trader](https://github.com/Morgan-Stanley/morphir-examples/tree/master/src/Morphir/Sample/Apps/Trader) - An automated - trading algorithm that makes decisions based on the market and the state of the current book of deals. It +- [Trader](https://github.com/Morgan-Stanley/morphir-examples/tree/master/src/Morphir/Sample/Apps/Trader) - An automated + trading algorithm that makes decisions based on the market and the state of the current book of deals. It relies on Books, Records, and Order. ## Modeling the Persistent App specification -All three of these are instances of applications that manage: + +All three of these are instances of applications that manage: ## Modeling the API -Books and Records is used by Order to book executions, so it needs a way to accept orders. We model this in Morphir + +Books and Records is used by Order to book executions, so it needs a way to accept orders. We model this in Morphir using the API type as such: ```elm @@ -55,14 +65,15 @@ type alias API = , closeDeal : ID -> Result CloseRequestFault Event } ``` -This states that Books and Records exposes an endpoint to open a deal and another to close an existing deal. In each -case, the outcome of the request is communicated by an event that either confirms or gives a message about why the -request was rejected. Note that it doesn't state whether these calls are synchronous or asynchronous. That's because -that decision is an infrastructure ecosystem concern, not a business concern. That means we should save the decision to -a later stage when we decide how the application fits into the ecosystem. If we decide now, we're locking ourselves to + +This states that Books and Records exposes an endpoint to open a deal and another to close an existing deal. In each +case, the outcome of the request is communicated by an event that either confirms or gives a message about why the +request was rejected. Note that it doesn't state whether these calls are synchronous or asynchronous. That's because +that decision is an infrastructure ecosystem concern, not a business concern. That means we should save the decision to +a later stage when we decide how the application fits into the ecosystem. If we decide now, we're locking ourselves to one execution paradigm before we have enough information. -We know that other applications will be interested in knowing what's happening in Books and Records even if they're not +We know that other applications will be interested in knowing what's happening in Books and Records even if they're not making requests. So we declare that Books and Records publishes events about what's going on: ```elm @@ -72,15 +83,17 @@ type Event ``` ## Modeling the Local State -Books and Records by definition owns the state required for book management. We want to declare what state is owned so -that we can plug it into our persistence ecosystem eventually. We do this with: + +Books and Records by definition owns the state required for book management. We want to declare what state is owned so +that we can plug it into our persistence ecosystem eventually. We do this with: ```elm -type alias LocalState = +type alias LocalState = Dict ID Deal ``` ## Modeling Remote State Dependencies + Some applications need information managed outside their domain. The Order application demonstrates this. It declares these external dependencies using the RemoteState type: @@ -94,45 +107,49 @@ type alias RemoteState = } ``` -Here we state that Order depends on the ability to book order executions, to look up the current state of a deal, -to get the current market price for a product, and to get the product's inventory. It needs all of this information to -make decisions. Notice that it doesn't specify what's going to satisfy these dependencies. That's an infrastructure +Here we state that Order depends on the ability to book order executions, to look up the current state of a deal, +to get the current market price for a product, and to get the product's inventory. It needs all of this information to +make decisions. Notice that it doesn't specify what's going to satisfy these dependencies. That's an infrastructure ecosystem decision based on knowledge that we don't have as modellers. ## The Full Models -These three patterns cover most applications. For the full example models take a look at + +These three patterns cover most applications. For the full example models take a look at [the Morphir examples project](https://github.com/Morgan-Stanley/morphir-examples/tree/master/src/Morphir/Sample/Apps). # Execution -There are many ways that we can run these applications. The advantage of modeling them is that we can choose and -customize as needed without rewriting any of our core business concepts. For this example, we will take advantage of -the fact that Microsoft has recognized this very set of patterns in its cloud-ready [Dapr Platform](http://dapr.io). Each + +There are many ways that we can run these applications. The advantage of modeling them is that we can choose and +customize as needed without rewriting any of our core business concepts. For this example, we will take advantage of +the fact that Microsoft has recognized this very set of patterns in its cloud-ready [Dapr Platform](http://dapr.io). Each of our modeled patterns has a corresponding Dapr feature that we can take advantage of. Our model patterns map to Dapr in the following ways: -* **API Requests** - Our API requests turn into REST services defined by generating OpenAPI specifications. Alternatively, +- **API Requests** - Our API requests turn into REST services defined by generating OpenAPI specifications. Alternatively, we could choose to use a message queue or Kafka for asynchronous requests. -* **API Events** - Events are published to Kafka as event logs. -* **Local State** - Dapr supports Redis natively, so we'll use that for persistence. -* **Remote State** - Given that we've made the REST decision, all the external applications will also be exposed that +- **API Events** - Events are published to Kafka as event logs. +- **Local State** - Dapr supports Redis natively, so we'll use that for persistence. +- **Remote State** - Given that we've made the REST decision, all the external applications will also be exposed that way. These will turn into REST calls and get bound to the owning applications during the SDLC pipeline. For more information on Morphir's Dapr support, take a look at the [morphir-dapr](https://github.com/Morgan-Stanley/morphir-dapr) project. # SDLC Pipeline -We can utilize various SDLC technologies to create straight-through deployment. In this example, we'll utilize GitHub's -pipeline technology to trigger a full deployment lifecycle every time we make a change to the model. + +We can utilize various SDLC technologies to create straight-through deployment. In this example, we'll utilize GitHub's +pipeline technology to trigger a full deployment lifecycle every time we make a change to the model. # Summing Up -In this example we've created a full set of distributed applications using Morphir, and we've managed to do so without -writing a single bit of non-business code. The cool part is that it doesn't mean that we're locked into a particular -platform or vendor. We can always change the execution target by using another Morphir backend or writing our own. -We've also demonstrated a true front-to-back SDLC pipeline that automates full deployment from the moment you check in your model. +In this example we've created a full set of distributed applications using Morphir, and we've managed to do so without +writing a single bit of non-business code. The cool part is that it doesn't mean that we're locked into a particular +platform or vendor. We can always change the execution target by using another Morphir backend or writing our own. + +We've also demonstrated a true front-to-back SDLC pipeline that automates full deployment from the moment you check in your model. -The end result is an application development that finally **lets developers focus solely on providing business value -without sacrificing technical flexibility**. That should be pretty compelling to anyone who's struggled to balance +The end result is an application development that finally **lets developers focus solely on providing business value +without sacrificing technical flexibility**. That should be pretty compelling to anyone who's struggled to balance providing business value against all the cursory development tasks. -[Home](/index) | [Posts](posts) | [Examples](https://github.com/finos/morphir-examples/) \ No newline at end of file +[Home](/index) | [Posts](posts) | [Examples](https://github.com/finos/morphir-examples/) diff --git a/docs/background.md b/docs/background.md index 70e079d8d..8ef1c577c 100644 --- a/docs/background.md +++ b/docs/background.md @@ -1,67 +1,79 @@ +--- +sidebar_position: 2 +id: background-story +title: The Morphir Background Story +--- + # The Morphir Background Story -Morphir evolved from years of frustration trying to work around technical limitations to adequately model business concepts. Then after so much effort and pain, we inevitably have to start over to adapt to some new technology. This came to a head when one of our businesses suddenly faced a convergence of major new business requirements and technical upgrades that required yet another major rewrite. There was so much work to be done and so much frustration from our business clients that they issued the challenge below... + +Morphir evolved from years of frustration trying to work around technical limitations to adequately model business concepts. Then after so much effort and pain, we inevitably have to start over to adapt to some new technology. This came to a head when one of our businesses suddenly faced a convergence of major new business requirements and technical upgrades that required yet another major rewrite. There was so much work to be done and so much frustration from our business clients that they issued the challenge below... ## The Challenge -> **Stop the cycle of rewrites** - Our users recognized that we were in a constant cycle of upgrading technology. Each pass in the cycle required significant effort and posed the risk of implementing core business logic incorrectly. +> **Stop the cycle of rewrites** - Our users recognized that we were in a constant cycle of upgrading technology. Each pass in the cycle required significant effort and posed the risk of implementing core business logic incorrectly. -> **Stop making us use multiple applications with inconsistent values** - Our users noticed that different systems came to different results for what should have theoretically been the same calculations. As a result, they had to navigate across applications to get the information they needed. +> **Stop making us use multiple applications with inconsistent values** - Our users noticed that different systems came to different results for what should have theoretically been the same calculations. As a result, they had to navigate across applications to get the information they needed. > **Show us that the system is behaving correctly** - Our users demanded that if we were going to rewrite core business logic again, we needed to provide transparency so that they could understand exactly how the system was behaving with respect to the business. > **Deliver faster** - A never ending, desired request. ## Common Cause -This challenge made us re-examine our whole development process. It soon became clear that there was a theme across them: **the fundamental issue was the fact that the business knowledge was tightly wrapped into the technologies of the moment**. It stood to reason that freeing the business knowledge from the technology would address these challenges. That's the approach we took and that is what eventually evolved into Morphir. + +This challenge made us re-examine our whole development process. It soon became clear that there was a theme across them: **the fundamental issue was the fact that the business knowledge was tightly wrapped into the technologies of the moment**. It stood to reason that freeing the business knowledge from the technology would address these challenges. That's the approach we took and that is what eventually evolved into Morphir. ## Morphir In Action -Let's take a look at what that all means and how Morphir works to address these challenges. Let's consider a component of an online store application. The purpose of this application is to decide on: +Let's take a look at what that all means and how Morphir works to address these challenges. Let's consider a component of an online store application. The purpose of this application is to decide on: ### Promoting Business Knowledge -The business concepts underlying your application are its most valuable asset. It's often difficult to discern -business concepts when they're embedded within platform and execution code. On top of that, many programming languages + +The business concepts underlying your application are its most valuable asset. It's often difficult to discern +business concepts when they're embedded within platform and execution code. On top of that, many programming languages are so full of abstractions that it can become difficult to understand the business meaning at all. Morphir tackles this challenge in a few ways. First, it provides a common structure to save business concepts, including -both data and logic. This is the Morphir IR. The key to this structure is that it focuses solely on business logic and +both data and logic. This is the Morphir IR. The key to this structure is that it focuses solely on business logic and data. No side effects (like saving to a database or reading from a file) are allowed. The IR is the core to Morphir and allows it to work across languages and platforms. -Having an application's business knowledge in a common data structure allows teams to build useful tools that promote -knowledge dissemination. Some useful examples include interactive visualizations that allow users to understand the -application's logic, interactive audit tools to replay calculations interactively, automatic data dictionary and data -lineage registration, and more. +Having an application's business knowledge in a common data structure allows teams to build useful tools that promote +knowledge dissemination. Some useful examples include interactive visualizations that allow users to understand the +application's logic, interactive audit tools to replay calculations interactively, automatic data dictionary and data +lineage registration, and more. -The combination of these creates an ecosystem where users, new developers, and support personnel can gain insight into +The combination of these creates an ecosystem where users, new developers, and support personnel can gain insight into an application interactively without requiring developers to go back and study stale documentation and arcane code. ### Showing Correctness + If you're going to treat business knowledge as a valuable asset, you want to make sure that it's correct. Morphir's use of functional programming structures that are tuned towards codifying business concepts eliminates many of the bugs that -are common in less concise tools. This is really just the beginning of the story. What's even more powerful is the fact -that Morphir is compatible with a variety of source languages, so it can take advantage of the powerful tools that they +are common in less concise tools. This is really just the beginning of the story. What's even more powerful is the fact +that Morphir is compatible with a variety of source languages, so it can take advantage of the powerful tools that they offer. We currently support the [Elm programming language](http://elm-lang.org) due to its simplicity and power. The Elm compiler is supercharged to catch huge classes of bugs. The common saying is that if it compiles, it's guaranteed not to -have runtime errors (excluding limitations of the physical environment, of course). Another particularly exciting -language is Microsoft's [Bosque programming language](https://github.com/microsoft/BosqueLanguage), which takes the +have runtime errors (excluding limitations of the physical environment, of course). Another particularly exciting +language is Microsoft's [Bosque programming language](https://github.com/microsoft/BosqueLanguage), which takes the ability to verify program correctness up whole other level. Keep an eye out for further progress in this space. -Finally, the aforementioned business knowledge tools are a big help in establishing correctness. When users have the -ability to fully understand the system with helpful tools in real-time, it makes the user/developer feedback cycle very +Finally, the aforementioned business knowledge tools are a big help in establishing correctness. When users have the +ability to fully understand the system with helpful tools in real-time, it makes the user/developer feedback cycle very efficient. ### Delivering Faster -An important role of developers is to decide how the business concepts fit into an executable computer system. Once -that shape is decided, a great deal of the actual coding is very repetative and templated. Add to this the various best -practices and team standards and you get a lot of boilerplate code that can be automated for faster production with -fewer errors. Morphir relies heavily on such automation, which we call Dev Bots. As with any automation, smart use can -lead to drastic efficiency improvements, like taking seconds to generate what a developer would take days to + +An important role of developers is to decide how the business concepts fit into an executable computer system. Once +that shape is decided, a great deal of the actual coding is very repetative and templated. Add to this the various best +practices and team standards and you get a lot of boilerplate code that can be automated for faster production with +fewer errors. Morphir relies heavily on such automation, which we call Dev Bots. As with any automation, smart use can +lead to drastic efficiency improvements, like taking seconds to generate what a developer would take days to produce. Check out the [Dev Bot post](dev_bots) for more information on this topic. ### Eliminating Rewrites + Technology is evolving ever more quickly. It is no longer feasible to stay competitive if you need to completely rewrite -you application every time you want to upgrade to newer technologies. That's especially true if there is a risk of +you application every time you want to upgrade to newer technologies. That's especially true if there is a risk of getting your core business logic wrong in a rewrite. In addition to automating boilerplate code, Morphir Dev Bots convert Morphir IR into system code. This means the same Morphir model can run in different technologies. And with the business concepts protected in the Morphir model, there's no risk to losing it with the next big technology. Keep an eye out for @@ -69,8 +81,8 @@ the evolving list of target environments available in the Morphir ecosystem. Or, Morphir provides the tools to do it yourself. # Summing Up -Hopefully this gives a good background into what Morphir does and why. If you have any questions or comments, feel free -to drop us a note through the [Morphir project](https://github.com/finos/morphir). +Hopefully this gives a good background into what Morphir does and why. If you have any questions or comments, feel free +to drop us a note through the [Morphir project](https://github.com/finos/morphir). -[Home](/index) | [Posts](posts) | [Examples](https://github.com/finos/morphir-examples/) \ No newline at end of file +[Home](/index) | [Posts](posts) | [Examples](https://github.com/finos/morphir-examples/) diff --git a/docs/dev_bots.md b/docs/dev_bots.md index 353fed8f8..9b14ada4c 100644 --- a/docs/dev_bots.md +++ b/docs/dev_bots.md @@ -1,21 +1,28 @@ -# Dev Bots -The premise of Dev Bots is that we can and should automate a significant portion of the code that we currently write by hand. +--- +sidebar_position: 5 +id: dev-bots +title: Explaining Dev Bots +--- -Consider the portion of an application's code that is of no direct business value, includeing things like -persistence and ORM, interprocess communication, platform-specific code, object wiring, and more. We need this code -to make our applications run, but it is of no direct business value. A large portion of this non-business code comes -in the form of recipes to follow or "best practices" templates. The fact that it takes up the majority of our -applications often reduces us to human code robots. We often refer to this code as boilerplate, and it is +# Explaining Dev Bots + +The premise of Dev Bots is that we can and should automate a significant portion of the code that we currently write by hand. + +Consider the portion of an application's code that is of no direct business value, includeing things like +persistence and ORM, interprocess communication, platform-specific code, object wiring, and more. We need this code +to make our applications run, but it is of no direct business value. A large portion of this non-business code comes +in the form of recipes to follow or "best practices" templates. The fact that it takes up the majority of our +applications often reduces us to human code robots. We often refer to this code as boilerplate, and it is highly amenable to automation. -We can also look into automating certain aspects of business code. Much of that code also follows templates and best -practices, and as a result, there is an abundance of tools that process code for quality and conformance -to rules. These tools ensure that the code that developers write fits into a small window of variability. Again, -developers are reduced to human code robots. You have to wonder: *If we have such sophisticated tools that automatically -ensure that all of our code conforms to a limited set of templates after the code is written, why don't we have tools -that automatically write the code to those specifications in the first place?* The answer is that we can. +We can also look into automating certain aspects of business code. Much of that code also follows templates and best +practices, and as a result, there is an abundance of tools that process code for quality and conformance +to rules. These tools ensure that the code that developers write fits into a small window of variability. Again, +developers are reduced to human code robots. You have to wonder: _If we have such sophisticated tools that automatically +ensure that all of our code conforms to a limited set of templates after the code is written, why don't we have tools +that automatically write the code to those specifications in the first place?_ The answer is that we can. -This is what Morphir Dev Bots do. They automate the production of all the boilerplate and templated code and +This is what Morphir Dev Bots do. They automate the production of all the boilerplate and templated code and let developers focus on what they do best: provide the bridge between the business and computer world. -[Home](/index) | [Posts](posts) | [Examples](https://github.com/finos/morphir-examples/) \ No newline at end of file +[Home](/index) | [Posts](posts) | [Examples](https://github.com/finos/morphir-examples/) diff --git a/docs/index.md b/docs/index.md deleted file mode 100644 index 121c0ea95..000000000 --- a/docs/index.md +++ /dev/null @@ -1,83 +0,0 @@ -# Morphir - -Morphir is a multi-language system built on a data format that captures an application's domain model and business logic -in a technology agnostic manner. Having all the business knowledge available as data allows you to process it -programmatically in various ways: - -- **Translate it** to move between languages and platforms effortlessly as technology evolves -- **Visualize it** to turn black-box logic into insightful explanations for your business users -- **Share it** across different departments or organizations for consistent interpretation -- **Store it** to retrieve and explain earlier versions of the logic in seconds -- and much more ... - -While the core idea behind Morphir is very simple it's still challenging to describe it because it doesn't fit into -any well-known categories. To help you understand what it is and how you can use it to solve real-world problems we -put together a tutorial and list of questions and short answers: - -- [Tutorial](https://github.com/stephengoldbaum/morphir-examples/tree/master/tutorial) -- [How do I define my domain model and business logic?](#how-do-I-define-my-domain-model-and-business-logic) -- [How does Morphir turn logic into data?](#how-does-morphir-turn-logic-into-data) -- [What does the data format look like?](#what-does-the-data-format-look-like) - - -## How do I define my domain model and business logic? - -Morphir is a multi-language system, so it gives you flexibility in what language or tool you use to define your -domain model and business logic (we refer to them as frontends). As a community we are continuously building new -language frontends and if the one you are looking for is not available we provide tools for you to build it yourself. - -Our main frontend is currently the [Elm](https://elm-lang.org/) programming language. We support the whole language -(except for some very platform specific features like ports) so defining your domain model and business logic boils down -to writing Elm code. To learn more about the frontend see [morphir-elm](https://github.com/Morgan-Stanley/morphir-elm). - -Other frontends: - -- [Bosque Programming Language](https://github.com/Morgan-Stanley/morphir-bosque) - -## How does Morphir turn logic into data? - -The process of turning logic into data is well known because every programming language compiler and interpreter does -it. They parse the source code to generate an [abstract syntax tree](https://en.wikipedia.org/wiki/Abstract_syntax_tree) -which is then transformed into an [intermediate representation](https://en.wikipedia.org/wiki/Intermediate_representation) of some sort. - -Morphir simply turns that intermediate representation into a developer-friendly data format that makes it easy to build -automation on top of it. - -## What does the data format look like? - -It's easiest to start with an example. Say you have some simple business logic like this: - -```javascript -quantity * unitPrice -``` - -In Morphir's data format this would translate into something like this: - -```javascript -["Apply" -, ["Apply" - , ["Reference", [["Morphir", "SDK"], ["Number"], "multiply"]] - , ["Variable", ["quantity"]]] -, ["Variable", ["unit", "price"]] -] -``` - -# Further reading - -## Introduction and Background -* [Background](background) -* [Community](morphir_community) -* [What's it all about?](whats_it_about) -* [Working Across Technologies](work_across_languages_and_platforms) -* [Why we use Functional Programming?](why_functional_programming) - -## Using Morphir -* [What Makes a Good Model](what-makes-a-good-domain-model) -* [Development Automation (Dev Bots)](dev_bots) -* [Modeling an Application](application_modeling) -* [Modeling Decision Tables](https://github.com/finos/morphir-examples/tree/master/src/Morphir/Sample/Rules) -* [Modeling for database developers](modeling/modeling-for-database-developers.md) - -## Applicability -* [Sharing Business Logic Across Application Boundaries](shared_logic_modeling) -* [Regulatory Technology](regtech_modeling) diff --git a/docs/index2.md b/docs/index2.md deleted file mode 100644 index 065272543..000000000 --- a/docs/index2.md +++ /dev/null @@ -1,11 +0,0 @@ -## Where business meets technology - -Morphir turns a programming language inside out to provide ... - -> **Transparency** - Turn business rules into insightful data visualizations - -> **Agility** - Move between languages and platforms effortlessly - -> **Reliability** - No runtime exceptions, integrated testing and quality checks - -> **Transformation** - Renovate your applications in-place with no migration period diff --git a/docs/index3.md b/docs/index3.md index 00c5acccc..7f751fc0b 100644 --- a/docs/index3.md +++ b/docs/index3.md @@ -1,6 +1,12 @@ -# Maximize the soul of your application +--- +sidebar_position: 3 +id: soul-application +title: Soul of your Application +--- -Morphir approaches application development from the perspective that the application's business knowledge should be enshrined. Adopting this knowledge-first has brought us great benefits, including: +# Maximize the Soul of your Application + +Morphir approaches application development from the perspective that the application's business knowledge should be enshrined. Adopting this knowledge-first has brought us great benefits, including: > **Transparency** - Turn business rules into insightful data visualizations @@ -13,14 +19,13 @@ Morphir approaches application development from the perspective that the applica This has been impactful enough that we want to bring it to the open-source community. Morphir is all about potential. We have benefited and will contribute these. The true potential is in what the community can bring to the Morphir ecosystem. ## Why use Morphir? -Your application has a soul - it's reason for existing. It might be embodied in calculations, business rules, and other logic. Collectively these are your application's most important assets. You need to protect these assets. You also want to do useful things with it. - -For starters, you definately want it to **[function correctly](why_functional_programming)**. Ideally, it could do that **[across different technologies and platforms](work_across_languages_and_platforms)**. In addition, you also want to **[share the knowledge](shared_logic_modeling)** to your application's stakeholders. This provides transparency and gives them **[confidence](build_confidence)** in what you're delivering. It also makes supporting and learning about your application easier. The world is changing fast, so you want all of these characteristics while **[delivering quickly and efficiently](dev_bots)**. -This is where Morphir comes in. **Morphir treats logic like data**. This simple concept makes it possible to do all of these things and more. Morphir makes development better. To learn more ... +Your application has a soul - it's reason for existing. It might be embodied in calculations, business rules, and other logic. Collectively these are your application's most important assets. You need to protect these assets. You also want to do useful things with it. +For starters, you definately want it to **[function correctly](why_functional_programming)**. Ideally, it could do that **[across different technologies and platforms](work_across_languages_and_platforms)**. In addition, you also want to **[share the knowledge](shared_logic_modeling)** to your application's stakeholders. This provides transparency and gives them **[confidence](build_confidence)** in what you're delivering. It also makes supporting and learning about your application easier. The world is changing fast, so you want all of these characteristics while **[delivering quickly and efficiently](dev_bots)**. -[Home](/index) | [Posts](posts) | [Examples](https://github.com/finos/morphir-examples/) ------|------|------ - | | +This is where Morphir comes in. **Morphir treats logic like data**. This simple concept makes it possible to do all of these things and more. Morphir makes development better. To learn more ... +| [Home](/index) | [Posts](posts) | [Examples](https://github.com/finos/morphir-examples/) | +| -------------- | -------------- | ------------------------------------------------------ | +| | diff --git a/docs/intro.md b/docs/intro.md index 640e50c96..e7aac70ce 100644 --- a/docs/intro.md +++ b/docs/intro.md @@ -6,22 +6,86 @@ title: Introduction # Morphir -Morphir is an ecosystem of tools to harness the untapped power of an application's business logic. -- **Translate it** to move between languages and platforms effortlessly as technology evolves -- **Visualize it** to turn black-box logic into insightful explanations for your business users -- **Share it** across different departments or organizations for consistent interpretation -- **Store it** to retrieve and explain earlier versions of the logic in seconds -- and much more ... - -Morphir (current) features: -* **Write your business logic once, ever!** -* **Verify that your business logic is correct and complete** -* **Understand your business logic with interactive tools** - Morphir's insight tools allow users to interactively test and understand how your application behaves. -* **Easily write tests generated from your business logic** -* **Execute your business logic consistently across different language runtimes** -* **Translate your business logic into other programming languages** -* **Generate interactive documentation that's always up-to-date** -* **Integrate into data dictionary, catalog, lineage, and other data management tools** +Morphir is a multi-language system built on a data format that captures an application's domain model and business logic +in a technology agnostic manner. Having all the business knowledge available as data allows you to process it +programmatically in various ways: + +- **Translate it** to move between languages and platforms effortlessly as technology evolves +- **Visualize it** to turn black-box logic into insightful explanations for your business users +- **Share it** across different departments or organizations for consistent interpretation +- **Store it** to retrieve and explain earlier versions of the logic in seconds +- and much more ... + +While the core idea behind Morphir is very simple it's still challenging to describe it because it doesn't fit into +any well-known categories. To help you understand what it is and how you can use it to solve real-world problems we +put together a tutorial and list of questions and short answers: + +- [Tutorial](https://github.com/stephengoldbaum/morphir-examples/tree/master/tutorial) +- [How do I define my domain model and business logic?](#how-do-I-define-my-domain-model-and-business-logic) +- [How does Morphir turn logic into data?](#how-does-morphir-turn-logic-into-data) +- [What does the data format look like?](#what-does-the-data-format-look-like) + +## FINOS Morphir Resources + +- [Morphir Resource Centre](https://resources.finos.org/morphir/) + +| Episode | Description | +| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | +| | Introduction to the Morphir Showcase | +| | What Morphir is with Stephen Goldbaum | +| | How Morphir works with Attila Mihaly | +| | Why Morphir is Important – with Colin, James & Stephen | +| | The Benefits & Use Case of Morphir with Jane, Chris & Stephen | +| | How to get involved – Closing Panel Q&A | +| | Morphir Showcase – Full Show | + +## How do I define my domain model and business logic? + +Morphir is a multi-language system, so it gives you flexibility in what language or tool you use to define your +domain model and business logic (we refer to them as frontends). As a community we are continuously building new +language frontends and if the one you are looking for is not available we provide tools for you to build it yourself. + +Our main frontend is currently the [Elm](https://elm-lang.org/) programming language. We support the whole language +(except for some very platform specific features like ports) so defining your domain model and business logic boils down +to writing Elm code. To learn more about the frontend see [morphir-elm](https://github.com/Morgan-Stanley/morphir-elm). + +Other frontends: + +- [Bosque Programming Language](https://github.com/Morgan-Stanley/morphir-bosque) + +## How does Morphir turn logic into data? + +The process of turning logic into data is well known because every programming language compiler and interpreter does +it. They parse the source code to generate an [abstract syntax tree](https://en.wikipedia.org/wiki/Abstract_syntax_tree) +which is then transformed into an [intermediate representation](https://en.wikipedia.org/wiki/Intermediate_representation) of some sort. + +Morphir simply turns that intermediate representation into a developer-friendly data format that makes it easy to build +automation on top of it. + +## What does the data format look like? + +It's easiest to start with an example. Say you have some simple business logic like this: + +```javascript +quantity * unitPrice; +``` + +In Morphir's data format this would translate into something like this: + +```javascript +[ + "Apply", + [ + "Apply", + ["Reference", [["Morphir", "SDK"], ["Number"], "multiply"]], + ["Variable", ["quantity"]], + ], + ["Variable", ["unit", "price"]], +]; +``` + +