[wpietri]

Could you expand on this? I'm not seeing why the "duh" is warranted.

> Jolie, you write code that maps directly to the concepts that matter. What are the important concepts? APIs, Access Points, and Services (duh..) are examples.

I come out of the Domain Driven Design school of thought, where the true key concepts are the domain-related ones. E.g., if you're doing ecommerce, things like Product and Order are much more important. They're also much more stable. Over time what gets exposed as an API will vary much more than whether or not we have a Product or an Order.

What you're calling important is what I think of as implementation details. Important in the sense that pipe fittings are important to a house: vital, but very much secondary to the purpose.

[fmontesi]

I was indeed talking about implementation models, in particular models of service-oriented systems. These are usually formulated in terms of services, DTOs, APIs, business logic, etc., hence the value brought by Jolie in giving a direct syntactic representation. The model of an implementation can change often, so it's important to have code that resembles it closely (for readability, editing, etc.).

You're talking about the domain model, which I agree is more abstract and stable. It comes before making the implementation model. In the case of microservices, some concepts overlap and/or are very similar between domain and implementation, but some mapping is required. We started exploring a bit how to relate MDE languages to Jolie in https://arxiv.org/abs/2104.02458 and it looks pretty promising in the sense that they seem easily linkable.

In short: once you get to the implementation model and if this is service-oriented, Jolie gives you a concise and executable syntax to write it. (And there is ongoing work on how some elements of domain models can be mapped automatically to Jolie concepts.)

[wpietri]

Thanks for the explanation.

[rajandatta]

I'd say that you idea of Domaim is unduly restrictive. Yes, in an e-commerce or a merchandise based business, Products and Orders are domain objects. But services and ports and interfaces are every bit as real from a complementary domain - the domain Of software design and Technology Operations.

We are at historically bad levels of Interoperability because we don't really engineer software for management. We just call it an implementation detail.

Domains overlap. An e-commerce system will have a domain perspective to Infrastructure and the Infrastructure provider will have domain perspective on a Tennant like a specific e-commerce system. Bother are valid. There's real value in reducing the impedance between those views

[wpietri]

It's true both are valid, but I think you miss that the domain of software design and technical operations is a) secondary to and dependent on the actual business, and b) far less stable than the domain. As somebody who has written software and done ops for decades, I certainly value it. But I think it's a mistake to put it on an equal footing with the actual purpose of the enterprise.