SOA是什么？SOA具体实装出来到底是什么？
首先介绍下楼主的水平，楼主是个码农，没见过能用的详细设计，没见过什么是要件定义需求分析，从来不知道基本设计是怎么写出来的。

网上搜到的什么集成，什么耦合等等概念反正我是一句话没看懂。

提问前提：终究SOA作完会总会是程序吧？要不是的话我就不研究了。

程序就有输入输出调用等程序的基本要素，要么处理数据，要么调用别的什么东西处理数据。

我看那些概念感觉大概SOA就是让多系统（模块？）可以灵活整合吧？

那么假设有一个公司，有三个系统：生产管理、采购、库存管理

那SOA能对它们作什么？
SOA输入是什么？
输出又是什么？
它作了什么处理？

他是作为一个接口把数据标准化传来传去？

还是作为一个共通调用者来调用这三个系统中的各种功能？
------解决方案--------------------
你可以把SOA理解为一种概念，总的来说就是面向服务的设计。
这个概念简单来理解就是把之前所谓的模块划分做成服务。

比如之前的日志模块，需要引用你的dll，调用你的写日志方法来写日志。
这样当有多个系统时，就有一些麻烦：比如要做日志分析/统计的时候，可能每个系统都自己写一个日志分析/统计的工具。比如日志的存储，各个系统都要想办法申请空间去存储历史日志。

而如果把日志做成服务，这样各个系统就是通过服务接口来调用写日志的方法（可以是http接口，也可以是TCP/UDP，实现方式多种多样）。
遇到多系统的时候，各个系统不需要关心日志存储，日志分析/统计也可以交由日志服务来完成。

以上仅仅是一个例子，方便理解SOA的概念。
还有，不能说SOA就一定比之前的方式好，每种方式都有其优缺点，合适的就是最好的。
比如当你架构一个很小的系统的时候，SOA就显得繁琐，累赘了。
------解决方案--------------------
SOA只是一个被炒作过头的空洞的名词。你开发了一个系统，你可以给它贴上一个SOA的标签，以示高贵。

这就好比“高帅富”，它只是对某一群人的标签，你说你是一个屌丝，想要靠高帅富这个概念变得高级，似乎是办不到的。
------解决方案--------------------

引用:

Quote: 引用:

就是说当制造三个系统（生产管理、采购、库存管理）的时候都没有日志的功能，而是单独写一套日志的程序，然后通过SOA来调用？

SOA是果，不是因，怎么设计架构，怎么降低耦合，易于扩展是你的事情，做好了，就是“SOA”，做不好，你也可以吹自己做的是“SOA”。但是你打算“用SOA做”，那啥也做不了。有个笑话说，如何才能长寿，一个回答是，“一直保持呼吸，不要断气”，你真的把这个当作长寿秘诀了，那就是愚蠢了。
------解决方案--------------------

引用:

Quote: 引用:

就是说当制造三个系统（生产管理、采购、库存管理）的时候都没有日志的功能，而是单独写一套日志的程序，然后通过SOA来调用？

这个时候不要叫日志程序，要叫服务^_^
不是通过SOA来调用，是通过接口调用服务
这个所谓的接口，可以是http：比如post日志内容到一个url，也可以是tcp。

然后这个整体的设计叫SOA
------解决方案--------------------
在我认为就是一个统一的数据交换接口 内部包含了许多复杂的业务逻辑，对外公开的接口十分简单，不管你客户端用java  c#  或是手机等等，都调用这个统一的服务接口就行了