Artwork

Контент предоставлен Udi Dahan. Весь контент подкастов, включая эпизоды, графику и описания подкастов, загружается и предоставляется непосредственно компанией Udi Dahan или ее партнером по платформе подкастов. Если вы считаете, что кто-то использует вашу работу, защищенную авторским правом, без вашего разрешения, вы можете выполнить процедуру, описанную здесь https://ru.player.fm/legal.
Player FM - приложение для подкастов
Работайте офлайн с приложением Player FM !

[Podcast] Domain Models, SOA, and The Single Version of the Truth

 
Поделиться
 

Manage episode 65045183 series 63841
Контент предоставлен Udi Dahan. Весь контент подкастов, включая эпизоды, графику и описания подкастов, загружается и предоставляется непосредственно компанией Udi Dahan или ее партнером по платформе подкастов. Если вы считаете, что кто-то использует вашу работу, защищенную авторским правом, без вашего разрешения, вы можете выполнить процедуру, описанную здесь https://ru.player.fm/legal.

In this podcast we’ll try to describe some of the pitfalls of trying to split a domain model between multiple services, as well as how SOA side-steps the “single version of the truth” issue found in reporting.

Rishi asks:

Hi Udi,
First of all, thanks for all the posts and info you share, it is very insightful compared to loads n’ loads of marketing bull and vendor whitepapers. Ok, I have two questions for you.

1. I want to create a SOA-based LOB application/platform and I generally understand the ‘tenets of services’ and reasons for the same. However, as you may well know, there is a lot of interdependency between business constructs (such as a customer with an order, or a delivery with a product construct). Now, should we share these constructs within a tightly-coupled and domain-based “system” which exposes a number of services to the outside world and use the constructs directly inside the so-called “system” boundary. Or on the opposite spectrum have a number of autonomous and independent services that expose, own, and share certain business constructs or at least part of the data that represents them as a whole. For example, an order service will need to interact with a customer construct, which primarily/essentially is (or should be?) owned by a customer profile service – in this context, with clear, direct, and immediate inter-dependency what is preferable? Where do we draw the enclosing line?

2. In a line of business application, reporting and shaping data are a given necessity. Now, with autonomous and independent services which define business constructs in their contextual ways, how do we practically shape, combine, and filter data across various services? We certainly can’t do joins over multiple services in a practical way? And as some suggest, if we are to maintain duplicate or master data elsewhere, it just seems very messy to me – just consider having 3 versions of an order services, with 2 versions of support services, and ‘n’ number of other services to comb data from. Further, for reporting and also analytical purposes we really need to have business data structured in a well-defined manner, which for all purposes needs to be the “single version of the truth”. I can’t see granular services, with all its tenets, sitting nicely with such other requirements of the business – and yet I am not even asking them to be real-time. How do we meet such business requirements in your view with SOA?

Hope the above makes sense!

Cheers,
Rishi

PS: I use the word business construct purposefully, and it does not directly attribute to a well-defined programmable entity (in object-oriented way, that is).

Download via the Dr. Dobb’s site.

Or download directly here.

Additional References

Want more?

Check out the “Ask Udi” archives.

Got a question?

Send Udi your question to answer on the show.

  continue reading

21 эпизодов

Artwork
iconПоделиться
 
Manage episode 65045183 series 63841
Контент предоставлен Udi Dahan. Весь контент подкастов, включая эпизоды, графику и описания подкастов, загружается и предоставляется непосредственно компанией Udi Dahan или ее партнером по платформе подкастов. Если вы считаете, что кто-то использует вашу работу, защищенную авторским правом, без вашего разрешения, вы можете выполнить процедуру, описанную здесь https://ru.player.fm/legal.

In this podcast we’ll try to describe some of the pitfalls of trying to split a domain model between multiple services, as well as how SOA side-steps the “single version of the truth” issue found in reporting.

Rishi asks:

Hi Udi,
First of all, thanks for all the posts and info you share, it is very insightful compared to loads n’ loads of marketing bull and vendor whitepapers. Ok, I have two questions for you.

1. I want to create a SOA-based LOB application/platform and I generally understand the ‘tenets of services’ and reasons for the same. However, as you may well know, there is a lot of interdependency between business constructs (such as a customer with an order, or a delivery with a product construct). Now, should we share these constructs within a tightly-coupled and domain-based “system” which exposes a number of services to the outside world and use the constructs directly inside the so-called “system” boundary. Or on the opposite spectrum have a number of autonomous and independent services that expose, own, and share certain business constructs or at least part of the data that represents them as a whole. For example, an order service will need to interact with a customer construct, which primarily/essentially is (or should be?) owned by a customer profile service – in this context, with clear, direct, and immediate inter-dependency what is preferable? Where do we draw the enclosing line?

2. In a line of business application, reporting and shaping data are a given necessity. Now, with autonomous and independent services which define business constructs in their contextual ways, how do we practically shape, combine, and filter data across various services? We certainly can’t do joins over multiple services in a practical way? And as some suggest, if we are to maintain duplicate or master data elsewhere, it just seems very messy to me – just consider having 3 versions of an order services, with 2 versions of support services, and ‘n’ number of other services to comb data from. Further, for reporting and also analytical purposes we really need to have business data structured in a well-defined manner, which for all purposes needs to be the “single version of the truth”. I can’t see granular services, with all its tenets, sitting nicely with such other requirements of the business – and yet I am not even asking them to be real-time. How do we meet such business requirements in your view with SOA?

Hope the above makes sense!

Cheers,
Rishi

PS: I use the word business construct purposefully, and it does not directly attribute to a well-defined programmable entity (in object-oriented way, that is).

Download via the Dr. Dobb’s site.

Or download directly here.

Additional References

Want more?

Check out the “Ask Udi” archives.

Got a question?

Send Udi your question to answer on the show.

  continue reading

21 эпизодов

Все серии

×
 
Loading …

Добро пожаловать в Player FM!

Player FM сканирует Интернет в поисках высококачественных подкастов, чтобы вы могли наслаждаться ими прямо сейчас. Это лучшее приложение для подкастов, которое работает на Android, iPhone и веб-странице. Зарегистрируйтесь, чтобы синхронизировать подписки на разных устройствах.

 

Краткое руководство