我开始按3层（DAL，BL，UI）构建应用程序[它主要处理CRM，一些销售报告和库存]。
一位同事告诉我，我必须转向服务层模式，开发人员应从他们的经验中学到服务模式，这是设计大多数应用程序的更好方法。他说，将来以这种方式维护应用程序会容易得多。
就个人而言，我觉得它只是使事情变得更加复杂，我看不出有什么好处可以证明这一点。
这个应用程序确实有一个额外的小部分ui，它使用了一些（但只有少数）桌面应用程序功能，因此我确实发现自己在复制一些代码（但不很多）。仅仅由于某些代码重复，我不会将其转换为面向服务的，但是他说我还是应该使用它，因为总的来说，这是一个非常好的架构，为什么程序员如此热衷于服务？
我试图用谷歌搜索它，但是我仍然很困惑，无法决定该怎么做。
Answers:
马丁·福勒（Martin Fowler）的著作“企业体系结构模式”指出：
较容易回答的问题可能是何时不使用它。如果您的应用程序的业务逻辑仅具有一种客户端（例如，一个用户界面），并且用例响应不涉及多个事务资源，则可能不需要服务层。[...]
但是，一旦您构想出第二种客户端或用例响应中的第二种交易资源，就从一开始就在服务层中进行设计就值得了。
服务层提供的好处是，它定义了一组可供不同客户端使用的通用应用程序操作，并协调每个操作中的响应。如果您的应用程序具有不止一种类型的客户端，并且会使用其业务逻辑，并且具有涉及多个事务资源的复杂用例，那么在服务层中包含托管事务是有意义的。
使用CRM，销售和库存，将有许多CRUD类型的用例，其中几乎总是与服务层操作一对一对应。对域对象的创建，更新或删除的响应应通过服务层操作进行原子协调和事务处理。
拥有服务层的另一个好处是可以将其设计为本地或远程调用，或同时为两者而设计-并为您提供了这样做的灵活性。该模式为封装的应用程序业务逻辑实现以及各种客户端以一致的方式对该逻辑的调用奠定了基础。这意味着您还可以减少/删除代码重复，因为您的客户端共享相同的通用服务。您还可以潜在地降低维护成本-因为当您的业务逻辑更改时，您（通常）只需要更改服务，而不必更改每个客户端。
总而言之，使用服务层是很好的-而且-我想在您提供的示例中，因为听起来您有多个业务逻辑客户端。
With CRM, Sales and Inventory there will be a lot of CRUD-type use cases of which there is almost always a one-to-one correspondence with Service Layer operations-如果全部是关于多个UI的，那么CRUD如何进入这里？而且，即使CRUD与服务配合得很好，如果我不需要多个UI，如果我理解正确的话，我还是不会建立服务层，我真的希望我这样做是因为我更喜欢保持简单（服务层是弄乱我的经验）
添加服务层，因为您已经评估了该想法并得出了最佳方法：好的
添加服务层，因为这是所有很酷的孩子正在做的事情：不好
如果您的直觉说您不需要，那么就不要做。
在过去的十年左右的时间里，编程世界中最令人失望的发展之一是，它变得令人讨厌地以“时尚”为导向，人们追随潮流和潮流，就像他们是本季的鞋子一样。不要陷入陷阱。因为下个赛季“每个人”都会告诉您，您应该以其他方式进行设计。
服务层没有错也没有错-这是一种特殊的方法，应该根据其针对项目的技术优势来评估其适用性。不要因为自己的判断而被迫用他人的观点来代替。
创建服务层的决定有很多因素。由于以下原因，我过去创建了服务层。
情况1：您正在创建需要由众多不同客户端使用的基本功能。服务层为不同的客户端内置了功能，可以立即使用您提供的功能。
情况2：您通常将代码托管在应用程序空间中，但是您使用的许可证有限的第三方库。在这种情况下，您拥有想在任何地方使用的资源，但是数量有限。如果将其托管在服务背后，则整个组织都可以从其应用程序中使用它，而不必为每个托管主机购买许可证。
情况3：您正在构建第三方与您交流的功能。在您的示例中，您可以设置一个库存端点，以允许供应商将有关传入产品装运的消息传递给您。
案例4：您在整个企业范围内分析了代码，发现独立的团队创建了同一件事（只是实现方式略有不同）。通过服务层，您可以选择最佳方法，现在，您可以通过让他们加入服务，在所有团队中实施相同的过程。集中逻辑的另一个好处是发现错误时。现在，您可以一次部署此修复程序，并且所有客户端都可以同时享受这一好处。
所有这些都说对服务层有潜在的负面影响。
要点是，使您的系统服务导向并非总是灌篮。以我的经验，这通常是一个好主意（我倾向于以这种方式构建应用程序），但这不是自动决定。最后，您需要权衡利弊，并做出适合您情况的决定。
我见过的大多数服务层都是一团糟。服务往往有很多不同的方法，1500 LOC并不罕见。不同的方法没有共同点，但是共享代码。这导致高耦合，低内聚。它也违反了OCP，因为每次需要新操作时，您都必须修改代码而不是扩展代码库。从理论上讲，构造良好的服务层是可能的，但我在实践中从未见过。
CQRS解决了这些问题，使您不必创建这些过程服务层之一。
添加接口（服务层是接口的一种）需要花费时间。一个好的人需要花费很多时间进行设计和测试。第一次尝试正确使用它非常重要，因为稍后进行更改会破坏所有客户端。另外，请考虑，直到您有另一个需求稍有不同的客户端，您才可能不知道该界面中需要什么。维护服务本身就是一个永无止境的项目。
在大多数组织中，如果您去找企业赞助商并问他们：“您是否希望其他部门从我们的预算中开发（重用）我们正在开发的系统中受益？” 他们会嘲笑你的。首先让它为您的业务发起人工作，然后再开始重新使用该代码（在部门自己的时间）。
如果您知道，事实上，您今天编写的功能将被多个不同的服务客户端重用，那么请考虑从第一天开始设计服务层。如果不确定，或者项目中已经有许多未知数，请先进行一些简单的工作，然后在有时间和预算的情况下将其分为服务和客户端。从工作系统开始，在第一次尝试时正确设置服务接口要容易得多。
PS：如果您使用Java，那么Joshua Bloch在他的《 Effective Java》一书中都有许多很棒的界面建议。
我同意你的看法。如果您使用的是单个UI，则无需再包含一层。
DAL，BL和UI / Controller是设计应用程序的良好组合。如果您打算使用单个UI，则无需准备额外的层。在应用程序中增加1层只会增加开发工作量/时间。
另一个简化方案是在应用程序中使用多个UI，在这种情况下，最好有一个服务层来处理UI。