N-Layered .NET 4.0架构指南：面向领域的设计与实践

5星 · 超过95%的资源需积分: 9 13 浏览量更新于2024-07-31 收藏 10.47MB PDF 举报

《N-Layered Domain-Oriented Architecture Guide with .NET 4.0》是一本由业内知名专家编撰的技术指南，专注于介绍如何在.NET 4.0平台上采用N层（N-Layered）面向领域的（Domain-Oriented）架构设计方法。该书作者包括但不限于CesardelaTorre-Microsoft、Unai Zorrilla-PlainConcepts、Miguel A. Ramos-Microsoft等微软内部及外部的资深软件工程师和技术贡献者，如Diego Vega、Jonathan Aneja等人，以及一些 MVP（Most Valuable Professional）如Hadi Hariri（来自JetBrains）、Roberto Gonzalez等。 N层架构是一种常见的软件设计模式，它将应用程序划分为若干个独立且职责明确的层次，从底层的数据访问层（Data Access Layer），通过业务逻辑层（Business Logic Layer）处理业务规则，到表示层（Presentation Layer）与用户交互，再到可能存在的服务层（Service Layer）进行解耦。这种架构有助于提高代码的可维护性、可扩展性和复用性，尤其是在.NET 4.0环境下，它充分利用了.NET框架的优势，如.NET Framework的类型系统和面向对象特性。本书涵盖了以下核心知识点： 1. **基础概念**：对N层架构的原理和理论进行深入解析，让读者理解其背后的哲学和原则，如何将业务需求转化为层次分明的结构。 2. **.NET 4.0技术栈**：详细介绍如何在.NET 4.0中实现各层之间的通信，包括AOP（Aspect Oriented Programming）、ORM（Object-Relational Mapping）工具和WCF（Windows Communication Foundation）等技术的应用。 3. **领域驱动设计（DDD）实践**：探讨如何在.NET环境中应用DDD思想，通过领域模型、聚合根、值对象等概念来组织代码，提升代码质量。 4. **单元测试与架构设计**：如何编写有效的测试用例以验证各层功能，同时保证架构的健壮性和稳定性。 5. **案例研究**：书中提供了实际项目的案例分析，展示如何在不同场景下应用N-Layered Domain-Oriented架构，并从中学习最佳实践。 6. **团队协作与维护**：如何确保团队成员对架构有共同的理解，以及如何处理随着时间和需求变化而进行的架构调整。 7. **持续集成和部署**：讨论如何将N-Layered架构融入CI/CD流程，提高开发效率和产品质量。《N-Layered Domain-Oriented Architecture Guide with .NET 4.0》是一本实用的参考书籍，不仅适合.NET开发者进一步提升他们的架构设计能力，也适合架构师和项目经理了解如何在.NET 4.0时代构建高效、可维护的软件系统。

Prologues xv

Prologue by Aurelio Porras

(Developer Solution Specialist, Microsoft DPE)

I had the opportunity to participate in the development of some applications of a certain

relevance and I happily remember these meetings at the beginning of projects where

we drafted with boxes and arrows the architecture skeleton, we detected patterns and

labeled any element of the diagram with the latest technologies available that helped us

implement in the best possible way the required functionality without having to

reinvent the wheel. In these architecture discussions, the typical quarrels appeared

about the level of complexity of the application architecture to be implemented; on one

hand, the ones in favor of mounting a simpler architecture using code libraries and

implementations of patterns already built, to produce business logics immediately and

to present results as soon as possible, giving more freedom to the developer when using

technologies; and on the other hand, the ones in favor of building a more complex

architecture, building libraries and implementing patterns in accordance with the

application to speed up the production of business logics after that, although the results

appeared later, increasing the level of abstraction to prevent the developer from having

to make technological decisions. It was interesting to see how the “simplistic group”

rebuked the “complex group” the wasted effort in building unnecessary church arcs

that the technological infrastructure manufacturers in the following version would

make obsolete and tedium of the developer of business logics that sometimes stopped

being a programmer and turned into a mere person in charge of setting up the

architecture; and the “complex group” scolded the “simplistic group” for the amount of

duplicated code they threw away to the garbage and the effort in coordination they

wasted to avoid those functional duplicity problems by giving so much freedom to the

developer. Yes, it sounds like grandpa‟s stories that are told over and over, but these

were very amusing meetings.

The final result of these discussions was a series of architecture decisions

determining the technological infrastructure to be used to build the application, the

relationships with external systems, the organization of the code in layers, the libraries

already available for use, and the ones to be developed customized, among other

things. I remember in particular how we tried to de-couple parts of the application to

enable its future evolution, up to the limit allowed by the state of the art technology at

that time, to be able to modify or extend the business logics not having to touch all the

modules or to be able to interchange one of the external systems, the applications

server or the database with no problem.

But these architecture decisions were not only conditioned by technical factors such

as technological infrastructures, programming language or development tools; but also

by factors related to development of a software project such as budget and duration,

milestones and deliverables, experience of the development team, business knowledge

and all the things the projects have. At the end, architecture could suffer the unwanted

cuts due to “project decisions”.

So, unfortunately, I also had the chance to verify how certain architecture decisions

can condemn the future of great applications. I know the case of a financial application

that could adapt to business changes very quickly, thanks to the high level of

xvi N-Layered Domain-Oriented Architecture Guide with .NET 4.0

abstraction its architecture provides; the user himself is capable of modifying the

application logics through a visual tool and programming a pseudo-language of

business; the problem is that capacity of integration in line with other systems is very

limited because it is built on obsolete technologies and its coupling to them is such, that

the cost of migrating to the latest technologies is too high and is not justified from the

business point of view; especially if we consider that the application still works as a

charm and following the rule of our industry, if it works, don‟t touch it. I also know

other financial application that is well de-coupled from the applications server and the

database and it is relatively simple to update it technologically, but it did not take care

of the code organization and the business logics is so intricate in the different

application layers that it is not quickly adapted to changes as it would be good for

business, and streamlining it would involve rewriting most part of the application; this

is unthinkable, almost a new project. Surely, the two applications were created this way

due to the particular circumstances of the corresponding projects, but it is clear that

architecture decisions made at that time negatively affected the evolution maintenance

of those two applications, which, as it was expected from the beginning, would have

long duration in the production environment.

This is the root cause of this guide. Naturally, the state of the art technology has

changed a lot, the architecture trends, the capacities of modern technological

infrastructure, the new things in programming language and new development tools

help a lot to build weakly coupled architectures to enable evolution maintenance of the

applications; but if, also we conceive application architecture considering first the

importance of its future evolution, to adapt easily to the business changes and to add

the latest technologies replacing the oldest ones, we will be close to building a great

business application with healthy life guaranty.

And this is what the guide is about, building an architecture that de-couples the

business logics of the technology used to build the application so that one can evolve

independently from the other. And it does not only talk about birds and flowers, but it

also goes to a level of technical detail that will show us in the latest .NET technologies

and Microsoft development tools and its application in great business applications,

indicating when to use which technology and why, and including also the sample

application code following the precepts set forth throughout the whole guide.

I thank César for all this clarifying material, for his effort leading this initiative that

will surely help architects and developers to approach application architectures with a

more holistic vision, and I also thank the authors and collaborators that participated in

its preparation. Congratulations on the result.

Prologues xvii

Prologue by Israel Garcia Mesa

(Consultant - Microsoft Services)

We currently have a wide range of technological options we can use in our projects and

that cover many needs being detected through the years. The experience we have in

Microsoft Ibérica is that this variety of choices does not resolve all the problems of the

projects in our customers. The analysis we made and we continue to make to be better

every day has given us a series of conclusions we want to share in this guide.

Some thoughts about Architecture

The development of a software construction project is a process where many factors

are involved, and that is why it is important to have the suitable tools. Currently there

are many technological options available that help us compose our solutions, but,

however, they do not mitigate the main problems of a project:

 Needs of adaptation to changes in projects (functional and technical

requirements) that can have great impact on the effort.

 Uncertainty when choosing and using technology that best fits each

scenario.

 Integration with legacy systems that do not have a clear alignment with the

project requirements.

These and other situations can affect the development of projects and increase the

possibility of new risks appearing that impact on the project. To mitigate these risks the

following is recommended:

 The methodology of work must be adapted to our team, type of project and

customer, since this will be our tactic to meet our goal and all the details

must be considered. So it is important to choose a work method adapted to

the context of the project where the type of solution and work team must be

considered.

 Consider an architecture model that meets the known needs and with a low

coupling level, which will enable its adaptability. In this point different

options can be chosen when approaching the system, but following the

model proposed by the Domain Directed Design (DDD) can help us follow

the most suitable approach.

The design of the solution, besides being an incremental process, can be a process

to be performed from different approaches until completion of the solution vision.

From the experience gathered in the different projects we have developed we have

considered useful some approaches we summarize below:

 Solutions, of whatever size, are born from a global design where technical

aspects are not relevant (we could talk about conceptual design) and

subsequently design the parts of the solution as we focus on each one of

xviii N-Layered Domain-Oriented Architecture Guide with .NET 4.0

them. With this model, slowly, we will get closer to the details of

implementation de-coupling the design, reducing complexity and the

possibility that a technical problem can affect the rest of the solution.

 Also, it will be necessary to conjugate the design of the logical model with

the physical model or models, ideally an approach would condition the

other to the least extent possible. This type of approach enables reuse and

adaptability of the solution to the different scenarios.

There will always be a desire to build a solution around the idea that technology

will solve our problems, and we will think this is a shortcut to our goals. However, we

can discover this is not the quickest path since, when a design cannot grow and/or

evolve because it requires a lot of effort or we do not control the impact of such

changes, this is when the technology does not bring value to the solution and can

become a problem.

Additionally, there is a series of very useful tools to build a solution and that help us

to face changes in implementation and its design:

 Test Development: having unit tests and automated functional tests will

help us know the stability of our solution, and therefore determine if any

change could affect the solution and to what extent.

 Refactorization: approaching and implementing changes in a solution

through refactoring techniques is an efficient manner that helps us control

their impact. Complementing refactoring with the use of tests helps

reducing risks, so these are two perfectly complementary tools.

 Communication: a good communication inside the team reduces

possibility of working inefficiently or even duplicating functionality.

Besides it is a useful tool in our relationship with the customer, helping us

place common expectations, detecting new requirements or possible risks,

in quick and agile manner.

These conclusions that can seem logical and, however, so difficult to be carried out, are

the reason why we want to share knowledge of this guide so that our experience can be

useful in projects and so that technology becomes that tool that makes our job easier.

剩余474页未读，继续阅读

DoomLord

粉丝: 114
资源: 1318

N-Layered .NET 4.0架构指南：面向领域的设计与实践

[架构设计] .Net 4.0 面向领域多层架构指南 (英文版)

N-Layered Domain-Oriented Architecture Guide with .NET 4.0

sciter-sdk-4.0.0.7

[2]KAIWARTYA O, ABDULLAH A H, CAO Y, et al. Internet of vehicles: motivation, layered architecture, network model,challenges, and future aspects[J]. IEEE Access,2016,4(2):5356-5373.规范这篇文献格式

Deciduous Needleleaf Forests

比较CRF、GRAM-CNN、Layered-BiLSTM-CRF、MTM-CW和BioBERT模型在数据集JNLPBA、BC2GM、NCBI disease、BC5CDR、BC4CHEMD、LINNAEUS这6个数据集上的性能。

.net 架构师 面试题

用英文翻译 深度学习

最新资源

.net 架构师面试题

用英文翻译深度学习